The ultimate cloud email heresy

The ultimate cloud email heresy

Email systems seem to be in a perpetual state of migration. Since 1996, the on-premises implementation of Microsoft email technology has gone through nine major changes, or roughly one every two years. No sooner are you done and dusted with one migration than the next appears on the horizon. It’s a wonder that we get any real work done at all.

For the past few years the prospect of moving to the cloud, either “all-in” or in a hybrid configuration, has brought even more choice into the mix. Of course, one of the great advantages touted for the cloud is the prospect of “evergreen” technology. In other words, your cloud provider will take care of software updates and all the nasty details that surround migration and all you will have to do is contemplate the words justifying your promotion for being so intelligent in recommending the cloud solution.

Of course, life isn’t quite so straightforward. The way that cloud providers such as Microsoft and Google “light up” new features all the time, mostly without a great deal of warning, can generate a fair amount of heartburn for those who have to provide support to end users. The appearance of a new feature might create some questions from users. Taking back a feature, or hiding it in a new user interface, creates more impact.

Consider the change in UI in Outlook Web App (OWA) from the Wave 14 (Exchange 2010) version of Office 365 to the current version available in Exchange 2013/2016 or Exchange Online. Sure, there were excellent reasons for the UI makeover, including creating the foundation for OWA to be a better client for smartphone and tablet devices and to integrate a common app model, but the very different appearance caused some initial confusion. It's interesting to see the OWA design language being applied to the new Outlook.com web client. Some high-end features that you'll find in Exchange or Exchange Online are missing, but it's basically the same client, running on servers based in the same Office 365 infrastructure.  The two clients are busily swapping features like the transfer of features like Clutter from Office 365 to Outlook.com or the Sweep feature from Outlook.com to Office 365.

Outlook is better at hiding server changes because this client tends to chug away and doesn’t really care about the version of Exchange in the background. Until, of course, the time comes to dispatch an old version of Outlook to the byte wastebasket, something that occurred when Office 365 decided that it would not support Outlook 2003, a development subsequently echoed in Exchange 2013. Or the way that Exchange 2016 disdains any connection with Outlook 2007.

So change and migration happens even when your platform is evergreen or any other color you care to select. The search for new features (I won’t say perfection) and competitive pressures means that this is the way the email world works. It has been that way since Digital’s ALL-IN-1 and IBM PROFS competed for dominance in the corporate email market of the 1980s and Lotus cc:Mail and Microsoft Mail competed for PC LAN email sales in the early 1990s.

Which brings me to the point I want to discuss. That is, the proposal that free (consumer) email systems provide quite sufficient functionality and availability to meet the needs of many businesses. I know that this is the ultimate heresy, but it strikes me that many small businesses are quite happily using the free versions of Gmail and Outlook.com for their communication needs. I have no great evidence for this statement apart from the profusion of Gmail.com and Outlook.com email addresses seen on business cards, the sides of (white) vans, and other business paraphernalia.

Microsoft and Google have pumped huge sums into the development of their free email systems over the years. I think that these systems have benefited enormously from the engineering work done on their paid-for counterparts. You can equally argue that neither Microsoft nor Google could have launched their paid-for email solutions without the experience gained through Hotmail (now Outlook.com) and the early versions of Gmail, so it’s a bit of a virtuous cycle.

Given the investments in engineering, datacenters, and everything else that surrounds consumer email systems – and the more than reasonable record of availability delivered to their users – I think that they are a viable choice for small companies. And business-centric features like custom domain support are already available in Gmail and are coming to Outlook.com to help companies brand their communications.

Sure, there are many downsides. Support is the most obvious. Those frustrated at the telephone support delivered for Office 365 or Google Apps would be appalled to find that even worse support exists for their free counterparts. But it does. And there are other issues to overcome too, such as the lack of migration utilities, and so on. There's also the question of losing out on all of the functionality that exists across a suite like Office 365 when compared to "just email". That functionality is becoming broader, deeper, and more integrated over time. Evidence is seen in the Office 365 Compliance Center, a common launching point for policy-driven retention and preservation across all of Office 365. The Microsoft Graph is another example as are the applications that feed off the Graph such as Delve and Delve Analytics.

The clinching point for some is that a paid-for email service allows them to use a vanity domain, which is important when it comes to "appearing to be a big company" rather than a one- or two-person operation. And of course, if you're moving from an on-premises server, the ability to maintain a hybrid environment is a pretty big plus point, at least for Office 365.

But determination to save money is a powerful driver. Accepting that all will not be perfect when using a free email system is a good start in the consideration of these platforms as a viable option the next time a migration window opens. Just a thought…

 Follow Tony @12Knocksinna

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish