Have the recent widely publicized attacks on Microsoft Exchange made you realize that now is the time for someone else to run your organization’s email?
To recap: cyberespionage group Hafnium and other threat actors took advantage of previously undisclosed vulnerabilities in Exchange Server to hack into tens of thousands of Exchange Server machines facing the internet. In many cases, these were fully patched machines running the latest version of Exchange; in others, the Exchange Server boxes were running older versions lacking current updates. Microsoft issued patches for the vulnerabilities on March 2, but the vulnerabilities were widely exploited before then.
For most victims, the attackers left a back door on compromised machines, allowing them to return to wreak havoc later, even after patches are deployed. In other cases, information was exfiltrated; an investigation by security firm Volexity revealed that attackers were using the vulnerabilities to steal the full contents of users’ mailboxes.
Ouch.
It’s no surprise that this very prominent hacking event may be the catalyst for a lot of shops to reconsider whether running email is worth the hassle. The benefit of local control and amortized costs may now be outweighed by the cost of fighting these giant internet-wide attacks. Why not let someone else handle the security, patching, defense, and more?
The truth is, with a few notable exceptions, which I'll cover later in the story, it probably is time for you to retire your mail server administration hat and let someone else take care of the headache of running an email deployment. The resources that Microsoft and other cloud providers have in terms of operational excellence, security, and disaster recovery almost certainly dwarf your IT team’s budget and capabilities.
Your ability to fight spam and viruses may be strong, but is the time and money spent doing so really adding business value? Managing an Exchange cluster, including its storage, uptime, maintenance, and patching... unless you actually run an Exchange hosting business, chances are those tasks are just a way to keep the lights on and not advancing your organization’s business.
Of course, moving from an on-premises Exchange Server deployment to hosted Exchange is no small undertaking, and there’s a lot to consider before you take the plunge.
Hosted Exchange providers
One basic decision you’ll need to make is where to go for Exchange hosting. The 800-pound gorilla in the room is a subscription from Microsoft, whether it’s a Microsoft 365, Office 365, or Exchange Online plan. While the “365” subscriptions include various iterations of the company’s cloud-centric productivity suite, at the core, all of the plans are the same, relying on Microsoft’s hundreds of thousands of managed Exchange servers to send and receive billions of messages across and around the globe.
You may find yourself asking, “Who better to run Exchange than the people who make it?” and there is a certain logic to that line of thought.
But there are other ways to go as well. While many providers simply resell Office 365 and add a layer of end-user support or other additional services like journaling and enhanced spam protection, other companies like Sherweb, Rackspace, GoDaddy, and smaller companies will run a multi-tenant Exchange deployment that’s not part of Microsoft at all. If you’re just interested in mail and not the other services Microsoft 365 adds into the mix, these companies are worth investigating.
Issues and considerations
As you evaluate whether or not Exchange in the cloud is the right move for your shop, there are a host of related factors to consider as well. It’s not just where your mailboxes are, but all of the various and sundry supporting services that make for a well-run email service.
To hybrid or not to hybrid
One unique feature of Exchange versions since 2010 is the ability to operate a “split” or “hybrid” system for an organization where some mailboxes live in Exchange Online and others live on your regular, on-premises Exchange Server box. This has many benefits for larger organizations that have deep ties into the Active Directory and MAPI functionality of Exchange, including synchronization with identity management and HR systems, and it allows you to satisfy regulatory requirements of keeping some data where you control it and other less sensitive information under the control of your hosting provider.
Many (if not most) organizations use hybrid deployments for years, not days or months. Some consider the setup permanent. Unfortunately, this does not generally protect you against the types of threats that might be the catalyst for looking at a cloud move now, since you still have your on-premises infrastructure. But it is a stepping stone, and Microsoft’s vision is surely that even the most stalwart hybrid organizations will eventually give in and rely entirely on Exchange Online.
A caveat, however: even after a decade of running an Exchange hosting business, Microsoft for some reason has not figured out how, from a technical perspective, to have Azure Active Directory be an authoritative source of identities for its clients that began as hybrid clients. So even after all of your organization’s recipients live in the cloud — you could have a million mailboxes on Exchange Online and literally zero on-premises — you still have to have a machine running Exchange Server locally in order to manage users, because that Exchange Server is responsible for maintaining the Active Directory schema attributes for mail recipients in your organization, and Exchange doesn’t know how to look anywhere else.
Migrating
One of the hardest questions to deal with is how you migrate your existing data — in some cases, years and years of messages, attachments, calendar entries, and more — from your current Exchange deployment to wherever you are planning on hosting. It really depends on whether you choose a hybrid deployment or a “lift and shift”-style migration where you cut over to a new server on a certain date and stop using the old server for new mail.
There are numerous third-party services including SkyKick, CodeTwo, Quest’s Exchange Migration Manager, and others that can assist with the lift and shift migration, slowly bringing over mail in multiple passes so that you basically have a synchronized copy of all mail in the cloud as well as on your on-prem server and then running a last sync after cutover. With hybrid, it is relatively easy to use Microsoft’s tools to move mailboxes back and forth to Exchange Online.
Tip: one aspect to consider before migration is your retention policy. Would now be a great time to archive mail and other items older than 18 months or two years? Having to not move 1,500 copies of the 27MB PowerPoint presentation for the 2011 corporate retreat will save hours of migration time and a significant amount of bandwidth. That said, if your organization already has a formal retention/document lifecycle policy, it is best to move all of the data you are allowing to remain accessible in a clean sweep.
Backup and restore
How will you handle backup and restore operations? Microsoft generally asserts that Exchange’s built-in data protection, along with resilient hardware, is good enough to protect your data stored within its service, and it explicitly says it does not offer any other sort of backup.
Aside from catastrophic data loss, having hosted email doesn’t alleviate the problem of the mistakenly deleted email, the corrupt calendar entry, or the boss with the itchy trigger finger on the “swipe to delete” function on the phone. You’ll need to pay — most likely monthly — for another service to provide that critical backup and restore service, and your current backup solution probably will not extend to Exchange Online or other hosted providers.
Beware of folks who assert with vehemence that you do not need to back up Exchange Online; any real-world administrator needs the ability to restore items from a previous backup and not rely entirely on another party.
Giving up control
The biggest issue that many administrators and IT directors struggle with when moving to hosted email is the loss of control. IT has great responsibility for the security and protection of the business, and it has traditionally been through the exercise and application of control and permissions that IT carries out those responsibilities.
By turning over the entire operation to Microsoft or another hosting vendor, you get to offload the day-to-day responsibility — at the expense of the control. The vendor gets to decide maintenance windows. The vendor gets to decide on endpoint policies. The vendor gets to decide on the lifecycle of the current version, when upgrades happen, and when policies that support backward compatibility go away.
Licensing costs
You’re probably used to examining Exchange upgrade costs by looking at volume license server costs, attendant standard and premium client access licenses, and your hardware costs, and probably amortizing that for budget purposes over three to five years. The calculation for the cloud is more straightforward: number of logged in (not shared) mailboxes times monthly cost equals how much you need to anticipate hitting your credit card.
But what’s to say that monthly cost will always remain the same? After all, it is fair to wonder if, once the pendulum has swung toward the majority of mailboxes being hosted, the price wars will end and costs will rise? The cloud arms race will last as long as firms are solvent, but when some major players throw in the towel on competing for $3 and $4 monthly mailboxes, will the economics look as favorable for the cloud as they do now?
Alongside this, there’s also what I call WWML, the Weird Web of Microsoft Licensing. Exchange Online’s basic level of service is available to everyone at $4 per month, but do you want Office apps with that? Do you need a cloud-based phone system? Do you want the security and attachment protection features offered at a premium level only in a bundle? Do you still need to license some users for on-premises mailboxes if you are choosing a hybrid approach? And what if only some users need some features and others can just get by with the standard offering? The variables involved in determining monthly cost remain as complex, if not more so, as in the old on-premises days.
Managing downtime
First off, it’s hard to grasp the actual breadth of the Microsoft 365 / Office 365 service in terms of the network, hardware, and software that all come together to underpin the offering. That is a lot of stuff that can break — and I don’t know any customer, or even anyone at Microsoft, who would really seriously argue that Microsoft has been good at communicating about outages and their causes in the moment.
Meanwhile, you have a group of users potentially contacting your help desk in a surge of “Oh no! I can’t get mail” requests, and you have no control, no visibility over the problem, and no idea when services will be restored. Murphy’s Law also dictates that if there is an outage, it will affect your most vocal and visible users as well, in addition to anyone who vocally opposed your move to the cloud.
There is no solution to this — it’s just something to be aware of. While there are tools that monitor certain “endpoints” in the Microsoft 365 / Office 365 ecosystem over small intervals and report back, there isn’t really anything actionable for you with that information, other than to respond to your users with, “yeah, we know, we’ll let you know when it’s back.” Not amazing IT service.
Bandwidth concerns
In most places in the United States now, bandwidth is not generally an issue — email is not a huge data hog, although Exchange and Outlook can be chatty. But if you work in an office environment with multiple users and limited bandwidth, your experience could well be mediocre or worse.
Obviously, Microsoft’s data centers have few bandwidth and capacity concerns, but if you’re in a branch office with 20 people trying to hit Office 365 over a single pipe, you will be in trouble — especially if they’re all streaming Netflix as well. This is perhaps the most common surprise for smaller organizations used to a responsive local email server attached right on the network.
Do you need Exchange at all?
One last option to consider is moving away from Exchange entirely. While it’s beyond the scope of this article, business email can be done from standard IMAP and SMTP accounts and clients like Thunderbird or even Outlook configured to use mail standards and not Exchange protocols. While the extra collaboration and scheduling features of Exchange are nice, perhaps you can use other solutions for a fraction of the cost.
Or if you need collaboration but don’t want Exchange, consider standards-based groupware like Zoho or Zimbra. For a third alternative, maybe Google Workspace (formerly G Suite) is your answer — mail in the cloud and other Office-like apps to boot, but without the complexity of Exchange.
The bottom line is, if you’re making a move, it’s best to consider all of your options first.
How long does it take to move to the cloud?
It’s impossible to predict how long a full transition to cloud email will take, since it depends on how many mailboxes you have, how much data each mailbox stores, bandwidth constraints on your side, throttling constraints on the Microsoft side (the Microsoft 365 data centers throttle certain long-duration operations to ensure consistent service availability and to help prevent the “bad neighbor” scenario where one subscriber on an overprovisioned server does something heavy and takes the whole operation down), and other factors.
Typically if you do lift and shift and use a third-party data migration service, you’d let the service make multiple passes at migrating data over a month or two and then have a cutover date 60-90 days in the future. For smaller companies, it can be done in a weekend. For hybrid deployment, there is no set duration, as those types of setups are designed to be used over the long term.
In an emergency situation, you can have new inbound mail directed to almost any email provider within a few hours as long as you have a current list of users to set up, as well as access to your DNS and MX records to make the necessary changes. The migration of existing data and messages does not necessarily have to happen alongside the cutover to the cloud mail service, which can be a useful approach if you find you’re the victim of a Hafnium-style attack.
Who shouldn’t move to hosted Exchange
Of course, not every organization under the sun is well suited for Exchange in the cloud. Some shops simply need the control (as part of their accountability) of running their own mail. Others have fleets of specialized devices that sooner or later won’t talk to Exchange Online as it removes support for earlier versions of the TLS encryption service.
Other organizations don’t have the network bandwidth to support not having a local mail server, and still others will find that staying local for five, seven, or even ten years ends up being less expensive than paying for email monthly, setting aside the other arguments and ancillary benefits.
Organizations in highly regulated industries like financial services, healthcare, and law, and those in other industries with heavy burdens on information storage, may find the cost of the dedicated resources needed in the cloud makes hosted email an unfavorable decision.
Finally, Organizations with business processes set around email integration via MAPI to older versions of Outlook may need to remain on premises in order to retain control of the supported end clients. Microsoft occasionally makes waves about blocking access to Office 365 from older versions of Outlook and is now removing support for a lot of business plug-ins in newer versions of Outlook, so you may have a forcing function here that was not the case in Exchange Online’s earlier days.
The last word
If we are all being honest with ourselves, by most measurements — value to cost ratio, return on investment, security posture and profile — it makes sense for the average organization to host its email in the cloud. And generally, if you are an Exchange shop already, it makes the most sense to move to Exchange Online on its own or as part of a Microsoft 365 or Office 365 subscription.
Just be sure you consider all the options carefully, plan thoroughly, and prepare your users for the transition before pulling the trigger.