Cutover Migration – Field Notes

In my job as a consultant, I get all kinds of customers, assignments and problems to resolve. My latest project was to perform a cutover migration for a client that was migrating email for a subsidiary or recently acquired company into the cloud. They wanted a move that was quick, easy and painless. While I won’t say that migrations are quick and easy, the cutover migration has the makings of such a migration. No extra servers to install. Not a lot of configuration on Office 365 or the on-premise Exchange environment. Well. That’s assuming you’ve checked your environment for the usual and the unusual configurations. I am writing this article to detail some of the things that well as well as the challenges and issues that were experience during a cutover migration.

Environment

For cutover migrations, this client had a very typical setup that was ideal for a cutover migration:

  • Exchange 2007 SP3
  • Low user count ~ 25 mailboxes
  • No Public Folders
  • No on-site IT staff


The decision was made not to add complexity as well, so no DirSync server was installed and we would rely on the Cutover Migration Batch to create user accounts in the cloud. Even with the small size of the environment, typical Office 365 checks needed to be made:

  • UPN Check
  • Valid Domain check
  • Mail flow checks
  • Large item checks (now around 150MB)


In preparing for a migration I performed the following steps (not comprehensive, but a good starting pint):

  • AD Health Check
  • Reviewed Accepted Domains – use a script like this
  • Check GAL – review who needs to migrate and who does now.
  • Review Shared Mailboxes and Distribution Groups
  • Review mailboxes sizes – small pipe and large migration = long migration

Challenges
Despite our best preparation, things go awry or are missed in the pre-work that can affect the migration. Finding out that the client has not upgraded their pipe to something over a T1, can cause a long delay in the emails moving to the cloud. Having mailboxes with a significant number of items can also cause an issue. Having users listed as mailboxes, needing to be moved to the cloud and find they are hidden from the GAL. Licensing can also be challenging especially if you are combining purchased companies or switching to new licensing entirely.

Connection To/From On-Prem – SSL Req’d
This point would seem to be a no brainer, however, there are still companies that do not have valid SSL certificates, use no certificate at all or use self-signed certificates. All of these practices could potentially halt your migration to the cloud. In addition to the certificate, RPC over HTTP or Outlook Anywhere is required, secured with the previously mentioned SSL certificate.

Hidden Mailboxes
A Cutover migration batch connects to your environment from Office 365 to Exchange via SSL and Outlook Anywhere. Once connected, the batch will review the mailbox list and only really connect with mailboxes that are not hidden from the GAL. So before beginning a Cutover Migration, verify any mailboxes that do not need to move are hidden and that those that do are not hidden. This will save time and effort down the road.

Large Items
This one catches most clients by surprise. Especially if the client has had a policy in place for years that restricts emails to 25 or 35 MB in size. What we find is that mail messages from before that time are larger than that or we find internal emails are larger than the configured limit. The reason for that is usually the only parts reconfigured are the Receive and Send Connectors in Exchange. The problem is that these connectors will, on a single mailbox server, fail to stop internal emails that do not use those connects, but use Client Connectors which are usually not touched. So running the Large Item Script is extremely useful. In my last migration I made the same assumption of, well the connector is 25 MB, so there must not be any large emails. Only after having mailboxes fail did we realize that they had sent large internal emails of over 100 MB which required us to run a script to discover. Once the items were discovered, we removed them and proceeded with the rest of the migration.

Notifying Users
Office 365, especially a cutover migration, can be a big change for users. In my client’s case we had to redo the SmartPhone partnerships as well as Office software (Office 2010 upgraded to Office 2013). A good plan is to create a series of migration emails. A good range of emails would include an introductory email for the project as well as a quick explanation of what the user can expect. A second or cutover email would be a reminder of their cutover date plus instructions on what to do after they are migration. Lastly, a final email letting them know it was successful, what features to look for and who to contact in case of an issue.

Migration Batch – Restarting
The Migration Batch runs for the most part on its own with very little need for interaction or intervention. It should be monitored despite this because mailboxes will stall, large items will be found, and errors will occur. If there are issues, once they are corrected, a cutover migration batch can be paused and restarted.

With my previous migrations, I would try to keep track of data rates over time (slow links, lots of email, etc) and in general monitor the status for each mailbox being migrated. I could then see if there was a slow rate of mail transfer to the cloud or if all was progressing nicely. This would determine if I needed to do any troubleshooting or not.

Licensing
A migration item that is sometimes overlooked is licensing. Without a license a user won’t be able to download office, or use their mailbox. Make sure to do this either during the pre-staging process or right after the users were moved to the cloud. If changing plans during a migration (cutover or otherwise) make sure to get the licensing settles first because getting a license could take 24-48 hours depending on what is requested. Also double-check the mailboxes to be migrated require licenses or not (Shared Mailboxes).

Outlook Profile
Most Exchange migrations and even most Office 365 migrations, generally do not require a new Outlook profile. However, a Cutover Migration a new Outlook profile is necessary and will cause some end users a bit of difficulty when configured. Just something to keep in mind for the post migration stage.

Finalize the migration
Once all of the mailboxes are confirmed in the cloud, there are a few cleanup steps that should be taken:

  • License all users.
  • Turn off Exchange 2007 for a week
  • Make sure no one needs anything on the server.
  • Resolve any issues that crop up.
  • DNS Changes
  • MX Record – route email to Office 365 instead of Exchange
  • AutoDiscover
  • Any other Exchange related DNS records
  • Remove the Migration Batch in Office 365.
  • Check out the default Retention Policy in Office 365
  • Make sure it meets your needs
  • Modify or remove it from your users so no email disappears when least expected.
  • Download any Office software for the user base.
  • Configure SmartPhones and Outlook for Office 365.

Further Reading
Microsoft’s own Cutover Migration documentation:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s