Sean Wallbridge
As I mentioned in an earlier post, we have been in the process of migrating a customer to Office365 in preparation for their migration from SBS2003 to SBS2011 Essentials. We decided to move them to 365 well in advance of the server migration itself in order to lessen the “shock” of the migration to all concerned.
For the most part the migration from on-premise Exchange to Office365 hosted Exchange has gone quite well. Our customer opted for the “Small Business Package” for Office365 and we got them set up inside of a day. One thing we did do was elect to NOT host their DNS via Office365. This is something that might be confusing to many people when they first look at 365 as it seems like you MUST move DNS to 365 when you first read the set up documentation. If you read carefully you will find that this is not actually true and you can definitely use your own DNS management. You do need to create all of the records that Microsoft suggests or many functions of 365 will fail so “read and heed” the setup docs. In our case we could create all of the required records save one through the DNS management interface at HostPapa (where customer’s DNS is managed"). We had to request a manual record change be made by HostPapa support to complete all the necessary DNS record changes. One thing to note is that we set up the MX record to point at 365 as a much lower priority than the on-premise Exchange as on-premise MUST remain the primary receiver until after the migration is completed.
Once DNS was set up and the requisite 365 test was made against the customer’s domain we were able to start the actual migration process. 365 offers two distinct process for Exchange migration – Cutover and Staged. A Cutover migration assumes you are migrating everything within the on-premise Exchange to 365 while a Staged migration assumes you are migrating “chunks” of the current on-premise or you expect to be migrating over a long period of time or you expect to run in a hybrid mode (both on-premise and 365) for an extended period. There is more work involved with a staged migration and it requires the use of a “connector” tool between your AD and 365. A Cutover migration, on the other hand, relies solely on an RPC over HTTPS connection (think OWA) to “slurp” the data into 365. Our customer had a very small number of mailboxes to migrate so we elected to use the Cutover method.
All users were instructed to clean up their mailboxes so there was only one really large mailbox (just over 6GB) to migrate, all the rest were well under a gig. We set up a “migration batch” which defined all of the parameters required for the migration and kicked it off. Within a couple of minutes we could see that 365 was already importing mailbox data. The migration itself was started in the late afternoon and we allowed it to run until completed. The following morning it was obvious the migration had completed and it was also obvious that 365 had performed a synchronizing update with the on-premise Exchange sometime after the batch had completed. 365 will perform a synchronizing update once every 24 hours until the migration process is completed and you have shutdown the on-premise Exchange. This is because until you complete the migration and point the MX at 365 as the primary receiver, inbound email will still flow directly to the on-premise Exchange. If there is no sync between the two then new email would not make it into 365 while the MX still points at the on-premise Exchange.
In our case as all required mailboxes had imported properly into 365 we were able to make an immediate MX switch and we made 365 the primary receiver for email. As soon as the DNS record propagated we sent email to a couple of the users from our own Exchange and the emails arrived in the users 365 Inbox within seconds of being sent (we watched for this using 365 OWA). At that point we connected all users to 365 by creating a new Outlook profile in their Outlook 2010. All users with the exception of the user with the 6GB mailbox were fully updated within about 30 minutes from the point where there new profile for 365 was created within Outlook. The user with the large mailbox took considerably longer to fully populate Outlook as would be expected.
Overall, it took about 2 days from start to finish to go form on-premise Exchange to Office365 Exchange. It took the users a little bit to get used to being prompted for credentials when they logged into Outlook and they also had to get used to the fact that there might be a bit of a delay experienced when opening new items with large(ish) attachments. Otherwise, it all went much more smoothly than any of us – itgroove or the users – expected. We have seen an issue with the user with the large mailbox having some weird “connection” issues on start up of Outlook that, hopefully, will be solved shortly (looks like a corrupt profile problem). That issue aside, it has gone quite well and is certainly FAR easier than any on-premise migration I’ve ever performed between old and new versions of Exchange. We have a larger migration looming at another customer in a month or so and it will be interesting to see how it compares to this one as they have about 5 times as many mailboxes to migrate. I’ll keep you posted on our progress.