Microsoft’s August 7 TechNet post describing the process required to manually migrate an organization from Exchange hosted on Business Productivity Online Services (BPOS) to Office 365 says that anyone who wants to accelerate their transition to Office 365 can attempt a manual migration, providing that they are used to Exchange server migrations and accomplished in PowerShell. There’s no mention of easy access to heartburn pills and the large quantities of caffeinated beverages needed to fuel the migration, but I guess that these are just details. For those who can’t stomach the idea of playing with PowerShell scripts or taking on any of the side-effects mentioned in the post, the strong advice is to stay put and wait for the Office 365 team to come calling when they are ready to perform the migration.
The post provoked two thoughts in my mind. First, I’m sure that Microsoft deliberately intended to get across the idea that customers should not attempt to do the job themselves. Issuing warnings about potential dire consequences and lack of support will serve that purpose. For example, stopping mail flowing into a company for at least a day and losing any information archived into the Exchange Hosted Archiving solution seem like pretty dramatic side-effects of attempting a manual migration.
Stopping mail flow means that no inbound email will arrive and that any messages sent to an organization during the migration will be returned to sender, address unknown, no such number, etc. because Microsoft will have to delete and then recreate the organization’s email domain behind the scenes.
All of this doesn’t sound like a great proposal to make to company management, so it’s probably best to take Microsoft’s advice and wait for “a couple of months” before the Office 365 team makes contact to plan an automated and hopefully graceful migration with no potential for data loss.
Second, the sheer fact that Microsoft felt compelled to issue such a warning exposed just how much work and potential cost lies ahead of companies running BPOS today as they prepare to migrate to Office 365 in the future. I’m not quite so sure whether Microsoft intended to expose so much of their dirty washing, but it’s now all out in the open.
To understand why difficulties might exist in moving from BPOS to Office 365, we have to recognize that the first version of Exchange Online was based on Exchange 2007 whereas Office 365 is very much based on Exchange 2010. Indeed, a large part of the engineering effort devoted to both Exchange 2010 and Exchange 2010 SP1 had the firm intention of making Exchange easier to deploy and manage in a hosted environment. While they share large parts of a common architecture (much more so than Exchange 2003 and Exchange 2010, for example), no one can pretend that Exchange 2007 and Exchange 2010 are more than close cousins. Maybe kissing cousins, but no more than that.
It should therefore come as no surprise that the background operational processes and tools used to manage BPOS and Office 365 might be a tad different. “Operational” in this context doesn’t just refer to the work done to keep Exchange running. It also includes all the manual and automated processes used to create a dedicated Exchange Online instance for a large customer (more than 5,000 seats) or to bring smaller customers into the shared Exchange Online environment used by BPOS. And then there’s the documentation (both operational and marketing), the support processes and ticket handling, the training for administrators, Microsoft consultants, and partners, and all of the lore that builds up around any version of a large software product.
It’s true that some large customers who have recently moved to BPOS use Exchange 2010 SP1 rather than Exchange 2007. But these customers are still bound into the BPOS management and support systems rather than an Office 365 equivalent as that infrastructure won’t be fully ready until sometime in 2012. At that point, Microsoft plans to migrate BPOS customers to Office 365. And when that’s all done, we can stop using the world’s most meaningless name for office software.
CIOs who committed to BPOS since its launch in 2007 because they would see lower costs on an ongoing basis will hardly welcome the idea that additional cost is on the way but that’s the hard fact that they will have to incorporate into their 2012 spending plans. Migrations cost to prepare, execute, and manage and there’s no way around that. At least, no way until someone invents the auto-magic pixie dust to enable costless software platform migrations. Not in my lifetime!