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
Stage 1, may be easy for a small company but for large compaines? I assure you that’s not the case. Your talking 6 months if your are lucky just to get Legal/ediscovery and Information Security to agree to office 365. Discussions such as what AD attributes infosec will allow to be synced up to Microsoft’s cloud. We haven’t even talked about global companies which have sites in EMEA and where mailboxes have to stay in EMEA, and can’t be synced to an US based MS datacenter. Many many many issues to be resolved just to get off the ground… as I’m sure you know.
Beside from many migration issues to Office 365 today, I think the number 1 reason companies are NOT going to Public Cloud / Office 365 today is NSA PRISM news I.E. even US-Based companies suspect a backdoor access to the Public Cloud servers / Office 365 servers and this has been revealed in the NSA PRISM documentations.
@John: I completely agree! Public Cloud is dead in Europe! I recently had a customer here in Germany, a university, who wanted to migrate 10.000 student Mailboxes from a Linux system to Office 365. They had the idea before PRISM became public. After, they decided to do an Exchange 2013 on premises migration.
Same is happing in US too, I had customers cancelled Public Cloud project such as Office 365.
Unkess you have serious need for Exchange due to other apps there are options like Open Xchane or Gordano Mail and more.
Some may find this unfounded, but I think that MS ultimate goal is to kill on prem version of Exchange.
Or use Domino and you will save tons of € s on hardware and OS cost as you already have Linux experts it seems.
Direct access to the Public Cloud servers is part of the NSA PRISM program and documents are supporting that, Office 365 is Public Cloud so companies are not naïve.
Let’s all forget about Public Cloud / Office 365 and buy Tony Redmond’s Exchange 2013 On-Premises book 🙂 and build a great Exchange 2013 On-Premises for our customers 🙂
Or prhaps Tony can write few about Domino as well and we will all be really happy:)
As usual, a fairly good article Tony! I just wanted to chime in on a couple of points:
1) Pilots can be more complicated than a couple of hours of setup, depending on how extensive they need to be. In my mind, a pilot is a step beyond the testing/proof of concept stage; we’re tying into production systems with carefully selected users to help find and iron out the remaining problems with integration. In other shops, they use “pilot” to mean what I’d call a proof of concept: a test environment not connected to production. Both meanings seem to be in common use, so it is always important to be clear on terminology and expectations.
2) I have seen several companies — not the majority, but not an insignificant minority, use this kind of migration precisely as an opportunity to clean out mailboxes by only migrating the past 60-90 days of mailbox content. Any requests for material out that range are handled through backup/restore requests. They use the long migration timeframes and costs as their driver to adopt this change. There are always a privileged few who get the contents of their mailboxes manually exported and imported, but they are the exception, not the rule. I am surprised by how many companies are willing to take a one-time break in some aspects of fidelity in order to accomplish a migration in a tighter timeframe, especially when that break allows them to begin an across-the-board change in archival/retention policies.