Migrating from an on-premises Exchange 2016 server to Exchange Online can seem overwhelming, but doing it in ‘chunks’ makes it easier to plan and execute. Having done this a few times, I’ll show you how to overcome the tricky parts and avoid some ‘gotchas.’
Key Steps
Prepare your environment
Before beginning any migration, ensuring that your Exchange 2016 environment is up-to-date and healthy is essential. This includes checking for known issues, running updates, and performing a complete data backup.
Prepare your users
As with all significant changes, it’s vital to almost over-communicate to the end users what is going on. This is important not just for transparency and reassurance but also because you will need their cooperation in some things as you go along.
Plan your migration
Now that you have prepared the environment, you can plan your migration. This process includes determining the number of users that will be migrated, the migration schedule, and the migration method (such as a cutover or staged migration). Here are some things to look out for:
User Mailboxes
As part of the listing of users, make sure to get an updated list of users with very large mailboxes. The migration tool will refuse any mailbox over 99 GB in total size. I recommend you work with any users over 80 GB to either archive or delete mailbox items to get them below the 80 GB mark. Why 80 and not 90 or 95? It’s better to educate the user now rather than having to go back in a few weeks and address the issue again. Common mistakes here are that people will delete emails and not clean out the deleted items folder or delete a bunch of emails that do not affect the size much. Sort by attachment size in Outlook; start with the largest and work your way down.
Shared or Group Mailboxes
Identify “group mailboxes”. That is, any mailboxes used by multiple users, like a departmental mailbox. You will convert these to Shared Mailboxes as part of the migration process. As part of this step, verify the mailboxes are actually in use. Many times, a shared or team mailbox will, over time, fall into disuse. No need to migrate unused mailboxes! Identify any mailboxes belonging to terminated users. Sometimes, these mailboxes are kept so the person replacing the former user can refer back to them or for business continuity reasons. These, too, will convert to Shared Mailboxes.
Service Mailboxes
Service Mailboxes, or those used by an automated service, can also be a bit sticky to untangle if your organization has undergone personnel changes. Typically, some services use these mailboxes to send emailed reports or as an input queue to trigger some automated sequence. Again, research is your friend here. Look to see whether any mail has been sent or received by the mailbox in the last six months. Once you have a list of inactive mailboxes, confer with the automation and integration team to verify if the mailboxes are needed. If no one knows, propose disabling the mailbox for a few weeks to see what breaks. You can always turn it back on. Find out how the service connects if the mailbox is needed and used. If it’s logging in directly to your mail server, the team in charge of that service will need to adjust it to log into the Exchange Online service. The exception to that is if it’s merely sending mail and not receiving it, then you can make allowances for that on a single exchange server that you will leave behind as a gateway. ( More on that later).”
Distribution Lists
Distribution Lists can be a pain all their own. Again, run reports on the usage of these distribution lists to see if they have received any internal and external mail in the last 3-6 months. The time frame will be dependent on your organization. If the list is not in use, send one email to the list asking if it’s still needed. If someone says they need it, set it aside for further investigation. After all, if someone thinks it’s needed but hasn’t been used, is it really needed? One good way to clean out distribution lists, if your organization has had lots of turnover is to verify if any active users are still a part of the list.
Cutover versus staged migration
The migration type or process you choose will largely depend on the number of users and your current email system. Microsoft has a great chart to help you decide here –Decide on a migration path in Exchange Online | Microsoft Learn
Perform a pilot migration
Before migrating all of your users, performing a pilot migration is a good idea. This will allow you to test the migration process and identify any issues that need to be addressed before migrating all your users. A good way to run a pilot is in two or three phases. I prefer to start with the Infrastructure or Exchange team since they are best suited to solve any minor issues. The next group is usually the rest of the IT department, minus any VP or CIO types. Once they are done, you should have a good routine for the migration process.
Migrate your users
After the pilot migration is successful, you can begin migrating your users. After your pilot group, next would be a group of low-volume users. These users are typically field employees or warehouse workers. In other words, folks that can tolerate a little email downtime if needed. After they are complete, start breaking your organization into batches to migrate. I recommend moving teams or departments together if you are doing a hybrid move. There can be some interruption of calendar sharing if one person is still on-prem and the other is in the cloud. There are ways to work around this, but unless the migration takes months, it’s best to minimize the impact and move ahead.
Test and validate
After migrating your users, or after each batch, if doing staged or hybrid, it is important to test and validate that the migration was successful. This includes checking that all users can access their email, calendar, and other data and that all data has been migrated correctly. Please note that you may see some errors and warnings during migration. Investigate them, and you will find it is often a malformed email in the Drafts folder or Deleted Items. Those you can safely ignore.
Clean up
After the migration is complete, it is important to clean up your environment. This clean-up will include decommissioning your old servers and deciding to transition to a “pure cloud” environment or maintain a hybrid environment. That decision discussion would take up several more rather long blog posts! Microsoft has excellent guidance on their Learn site here: How and when to decommission your on-premises Exchange servers in a hybrid deployment | Microsoft Learn.
That’s a rather long-winded conversation about migrating to Exchange online, but to be fair, it’s a big job! I’ll follow up with some of the PowerShell and other tools you can use for the discovery and planning part of the process.
