One of the dangers of speaking at conferences is that sooner or later someone will challenge you to prove a statement made on stage.In a number of keynote sessions at conferences over the last year, I have strongly recommended that companies who are considering moving their Exchange deployment from on-premises into the cloud must have a Plan B, just in case things don’t work out so well. You know, the best laid plans of mice and men scenario… In any case, the inevitable email popped into my inbox to ask “so what shape should Plan B take?” In other words, if I go to the cloud and then decide to revert to on-premises Exchange, how can the changeover be done?
It’s a good question and it’s one that no great experience exists in terms of good answers. We can see some foundations in place but until a company goes through the great withdrawal and publicly reports exactly what went right and what didn’t, we won’t really know what the right answer might be. So here goes with my current thinking on the topic.
First, it’s important to differentiate between Office 365 and the Exchange 2010-based hosted email services provided by other hosting companies. Office 365 is very much a “one size fits all” solution that does a fantastic job of providing the features designed into the service. Anything that falls outside the well-defined boundaries of Office 365 functionality is largely a no-go zone, if only because every change made to the system costs so much to design, engineer, test, implement, and manage. The largest companies who purchase a dedicated Office 365 instance from Microsoft have some additional flexibility, but not as much as you’d think.
Traditional hosted service providers tend to provide more personal customer support simply because the numbers they deal with are so much smaller than Office 365. As such, they are often more willing to consider supporting specific changes requested by a customer. However, I imagine that their willingness to help might be reduced if the question was how best to retreat from their service.
The second critical principle to grasp is that mailbox data is at the heart of the matter. An Exchange environment can be recreated on-premises and configured to meet company requirements without too much difficulty. But Plan B quickly runs into problems if you can’t move user mailboxes back on-premises reasonably easily. The bad news here is that mailboxes invariably swell once they’re moved to Office 365 and a 25GB quota becomes the norm. Moving 1,000 mailboxes with a 500MB quota to Office 365 is easy enough. Moving those same 1,000 mailboxes back after they’ve grown to an average of 5GB or more creates a more interesting challenge.
The good news is that Microsoft has done a lot of work to enable hybrid interoperability, part of which is to leverage the ability of the Mailbox Replication Service (MRS) to move mailboxes between Exchange organizations, or in this instance, between on-premises servers and the associated Exchange Online tenant domain. Thus, if you’ve deployed a hybrid Exchange organization, you have the capability for bi-directional mailbox moves and can therefore plan to gradually retreat from Office 365 by moving mailboxes off Exchange Online back to on-premises servers. Given the amount of mailbox data that has to be transferred across the Internet, this might be a slow process, but it is feasible. And once all the mailboxes are safely transferred back to home base, you can break the link that ties the hybrid organization together and revert to a classic on-premises deployment. At least, that’s the theory. It needs to be tested and validated to have 100% confidence in the approach, but at least more than a glimmer of light exists.
Given that Office 365 spans more than just Exchange, part of the detachment process has to consider any dependencies that might exist on Lync Online and SharePoint Online. If any dependencies are identified, steps have to be taken to create similar capabilities on-premises before the final link with Office 365 can be broken.
The situation is murkier if you’ve gone ”all-in” and moved everything to Office 365. Apart from online mailbox moves with MRS, Microsoft’s other migration tools are great for moving data to Office 365 because that’s what they are designed to do. It’s strictly a one-way street. I don’t see any evidence that the same tools can be convinced to move mailboxes back to on-premises servers. The same is true for third-party migration tools from companies like Quest and Binary Tree. Logically, these companies see the commercial opportunity to move mailboxes to Office 365 rather than from Office 365, and I don't expect that they have any special magic that accelerates a movement back to on-premises.
The more inventive of you might be reaching for your PowerShell manuals in an attempt to create a purpose-designed migration script. Alas, the New-MailboxExportRequest cmdlet appears to be critical to any attempt to extract mailbox data from Exchange but this cmdlet is unavailable to Office 365 tenant administrators. Why? Well, the cmdlet depends on setting up network file shares and you don’t enjoy this level of control in Office 365. If you have a hybrid environment, you can run the cmdlet in the on-premises part to extract mailbox data from Office 365, but why would you do all this extra work when you can simply run New-MoveRequest to have MRS do everything instead?
Plan B is therefore an underdeveloped and poorly understood science. You might not care very much that such a state of affairs exists if you think it unlikely that you’d ever want to move away from Office 365. But five years ago how many of us considered a move from on-premises to a then non-existent cloud service might be a realistic possibility? Technology has a nasty habit of changing. In fact, it happens all the time. Shouldn’t we be prepared – just in case?
Follow Tony @12Knocksinna
