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.