Migration more complex than a simple methodology might indicate

Thinking about Microsoft’s new FastTrack 3-stage “sales and deployment methodology” for Office 365 projects, which aims to accelerate the rate that customers can move to their new cloud tenant domains (“to advance from pilot to deployment”). The new methodology is intended to allow Microsoft to compete better with Google as a perception exists that it takes more effort to move to Office 365 than to Gmail.

All email migrations are painful. I’m not sure that a new methodology is the answer. Stage 1 is all about deploying some pilot mailboxes and is something that can be done in an hour or so by any moderately intelligent human. As setting up both platforms for pilots is largely a matter of click, click, click through web pages, I can’t see how a Google deployment would be any faster. Moving on to Stage 2 and 3 (“Deploy” and “Enhance”) can be more technically challenging if you want to migrate any data from the old platform or establish ongoing connectivity between the old platform and Office 365. That could be simply a matter of setting up SMTP connectivity but it’s possible that the two-headed hydra of directory synchronization and hybrid connectivity come into view at this point.

It seems clear that this kind of approach is most suitable for those who want to migrate from non-Exchange platforms (like old IMAP or POP3 servers), or perhaps those (like universities) that have to cope with large numbers of transient users. Or companies that want to move off aging Exchange 2003 servers on a one-way transfer to Office 365 rather than execute an on-premises upgrade to a more recent version.

Why do I say this? Simple. All email migrations since the year dot have had to cope with two major issues: quantity and fidelity. Getting people to use their new Office 365 accounts is a great way to allow them to access the rich feature set of Exchange Online, SharePoint Online, and Lync Online, but it does nothing to move the huge amount of data that users tend to accumulate in their old mailboxes (the human packrat syndrome) nor does it do anything to ensure that data is moved in a form that it is useful when it gets to Office 365.

It might be acceptable to tell some employees that they have a new mailbox and to forget all of the information that exists in their old mailbox – or that they have to export to a PST and then import back into Office 365, but I doubt that this story would fly for anyone who has used Outlook to run their business life. Imagine losing your calendar, all of your contacts, and all of the email relating to current and old projects – not much fun, and a huge impact on personal productivity. The need to keep people productive and happy is the reason why email vendors and third parties develop migration tools.

In the early days of email, messages were pretty simple and the volumes much smaller than today. It used to be sufficient to export messages to text files and import them into the target system. We didn’t bother much with the various kind of item types that are used now – calendar, tasks, contacts, journal records, and so on. Everything was text, even the formatted attributes at the top of messages.

Today, some mailboxes are larger than the hard disks that we installed on servers in the 1990s. The quantity of mail that might have to be migrated can be problematic for any project simply because it will take time to move from one server to another. That time can be accelerated with fast internal networks but there’s not much you can do when the Internet bridges the gap between internal servers and the cloud. Moving a terabyte of user mailbox data can take a very long time.

Fidelity is the other concern. There’s no point in moving data if it’s not useful when it gets to the destination email system. That means items have to be transferred with all attributes intact so that users can continue to work with their calendar, that telephone numbers from their contacts work with mobile devices, they can respond to messages, and attachments are preserved. Simple but absolutely necessary.

And it’s not just the contents of mailboxes that have to be migrated. If you move mailboxes from an on-premises Exchange server to a cloud system, you’d like if those mailboxes come under the same kind of management regime that exists for on-premises mailboxes. For example, policy settings for client access, for instance, should be the same and retention policies and tags should exert the same control over mailboxes. In short, migration isn’t just all about moving data. That’s where you get into hybrid connections.

Microsoft has a good range of migration capabilities for Office 365, mostly built around the Exchange Migration Replication Service (MRS). Third parties like Binary Tree’s E2EComplete build on MRS to add better scheduling and automation, good attributes to have during migration projects. I imagine that these kind of utilities will still be required to move mailboxes to Office 365, even if Microsoft wants to fast track that activity. Quantity still exists and fidelity cannot be rushed. It’s always been the way.

Follow Tony @12Knocksinna