Exchange Server to Microsoft 365 Migration: A Pre-Migration Readiness Checklist

Sponsored content. This article was written and supplied by Stellar Information Technology, maker of Stellar Migrator for Exchange. SyncBricks edited it for clarity and publishes it as part of a paid partnership. Our own hands-on review of Stellar's PST repair tools is linked below.

Migrating from an on-premises Exchange Server environment to Microsoft 365 is not just a matter of moving mailboxes from one place to another. For most organizations, Exchange is connected to several other systems, including Active Directory, applications, SMTP relays, security tools, Outlook clients, and sometimes public folders.

That is why the work done before the actual migration can have a major impact on how smoothly the project goes.

Microsoft supports different ways to move Exchange mailboxes to Microsoft 365. The right choice depends on the Exchange version, number of users, identity setup, coexistence requirements, and how much downtime the business can accept. Before choosing a migration method, it is worth taking some time to understand the current environment.

Assess the existing Exchange environment

Before starting the migration, administrators need to make a list of the Exchange setup. This step helps find connections that might cause issues once users are moved to Microsoft 365.

The check should cover the Exchange Server version and the latest updates. It should also look at how many mailboxes there are and how big each mailbox is. The check should examine user mailboxes, resource mailboxes, distribution groups and public folders. Mailbox permissions need to be reviewed. Transport rules, connectors and SMTP relay settings must be checked. The check should also include journaling, archiving, third-party email gateways and any applications or devices that send email via Exchange.

The size of each mailbox and the number of items should also be looked at. Mailboxes that are very big, or folders with a lot of items, can slow down the migration process. Finding these problems before the migration starts helps administrators plan the migration groups and focus on the users who need the most attention.

Select the right migration strategy

The migration method should be chosen based on the organization's environment rather than simply using the approach the IT team is most familiar with. The method matters because each organization has different needs.

A hybrid migration can be useful when an organization needs Exchange Server and Exchange Online to coexist while mailboxes are moved in batches. Hybrid migration is suitable for environments where a gradual transition is required.

Smaller environments might consider a cutover migration instead. Minimal hybrid, also known as express migration, is another option for Exchange environments where organizations want to move mailboxes quickly without maintaining long-term directory synchronization.

The decision should consider the Exchange version, mailbox count and size, coexistence requirements, identity architecture, public folder requirements, technical expertise, migration timeline and acceptable downtime.

Validate Active Directory and Microsoft Entra ID

Identity is an important area to check before migration. If your organization synchronizes Active Directory with Microsoft Entra ID, you should make sure that users and groups are synchronized properly.

UPNs, SMTP addresses, proxy addresses, duplicate objects, disabled accounts and the scope of synchronization need to be checked. Administrators should also look at Microsoft Entra Connect or Microsoft Entra Cloud Sync, the way people sign in, multi-factor authentication, Conditional Access policies and Microsoft 365 licenses.

Users need Microsoft 365 licenses before their Exchange Online mailboxes can be used fully. Fixing identity and licensing problems before moving data prevents sign-in and mailbox access problems later.

Verify Exchange and connectivity prerequisites

Organizations using hybrid or remote mailbox moves should make sure the on-premises Exchange configuration is correct before moving production users. This means checking items like required Exchange services, certificates, accepted domains, Exchange Web Services virtual directories, permissions and migration endpoints.

For mailbox moves, the Mailbox Replication Service Proxy, also known as MRSProxy, must be set up properly. Migration endpoints should also be tested before starting any production migrations.

Running a test migration with a single mailbox is a good way to check connectivity, confirm permissions are working, verify that mailboxes can move successfully and make sure access works after the move. This helps avoid issues when scaling the project to all users.

Review DNS and mail flow

DNS and mail flow need planning because the migration changes where email is sent and how applications send messages.

Administrators should check MX records, Autodiscover, SPF, DKIM, DMARC, Microsoft 365 verification records, mail flow connectors, third-party email gateways and SMTP relay settings.

SMTP relay is very important. Printers, scanners, ERP systems, CRM platforms, monitoring tools and other programs might still use the on-premises Exchange server to send email.

A mailbox migration might look like it worked, yet an application could stop sending messages without anyone noticing because the SMTP link was missed. These links need to be found and tested before moving everything over.

Review permissions, shared mailboxes and public folders

User mailboxes are one part of an Exchange environment. Shared mailboxes, room mailboxes, equipment mailboxes, distribution groups and delegated permissions must also appear in the migration plan.

Administrators must check Full Access, Send As, Send on Behalf, calendar delegation, shared mailbox access and distribution group permissions.

Public folders need assessment if they are still used. Size, permissions, mail-enabled folders and application dependencies of folders must be recorded.

The goal is not just to complete a mailbox migration. The purpose is to make sure the business functions that users depend on remain in place after the move.

Check security and compliance rules

Microsoft 365 provides its own security and compliance features, but a company still needs to decide how its existing policies will operate in the cloud.

Before moving data, an administrator should check MFA, Conditional Access, retention policies, litigation holds, eDiscovery, auditing, Data Loss Prevention, archiving, encryption, journaling and any third-party compliance tools.

Test security rules with a group of users before the full migration. Otherwise a new authentication or Conditional Access rule could block users from opening their mailboxes.

Write down all compliance needs before moving data so that retention and legal rules stay the same and are not accidentally altered.

Perform a pilot migration

A pilot migration gives you a chance to spot problems early, before they spread across the organization. It is not enough to test a normal mailbox. The pilot should include different kinds of users: one administrator, one standard user, one executive, one user with a large mailbox, one mobile user and one user who has delegates or uses Outlook add-ins.

While the pilot is running, administrators need to check several things. They should verify that mailbox data is correct, test internal and external email flow, confirm Outlook is connecting properly, check that mobile access works, test calendar features, look at delegation settings, test access to shared mailboxes, review any SMTP applications and watch for any migration errors that pop up.

Once the pilot is done, the results can be used to improve the migration batches. Any issues found can be fixed before the real migration starts. This helps make the full migration smoother and more reliable.

Prepare a cutover and rollback plan

Every migration must have a documented cutover procedure that covers activities before, during and after migration.

Before cutover, administrators must confirm that migration endpoints have been tested, that the pilot has succeeded, that DNS changes are prepared, that users have been informed, that licenses are available, that backup procedures are confirmed and that application dependencies have been identified.

During cutover, the team must monitor mailbox migration, DNS changes, authentication and mail flow. Afterwards, administrators must continue monitoring outbound email, Outlook connectivity, mobile devices, SMTP applications, migration errors, security alerts and DNS propagation.

A rollback plan is equally important. The team must know what action to take if users cannot authenticate, if mail flow fails or if a critical business application cannot send email.

Consider a third-party migration tool

Microsoft's native migration tools can work well for organizations that have experienced Exchange administrators and simple needs. However, hybrid configuration, migration endpoints, permissions and PowerShell-based processes can become complicated for organizations with limited Exchange administration resources.

A third-party solution such as Stellar Migrator for Exchange can be evaluated as an alternative. The solution supports Exchange to Microsoft 365 migration and other Exchange environments, and provides capabilities such as mailbox mapping, incremental or delta migration, parallel migration, scheduling and migration reporting.

A guided Exchange migration tool can be especially useful when administrators want to simplify the mailbox migration process and reduce the amount of scripting involved.

However, a migration tool does not remove the need for infrastructure planning. Administrators still have to handle identity synchronization, licensing, DNS, mail flow, SMTP applications, security policies, compliance, permissions, client compatibility and backup and recovery.

Organizations should look at third-party approaches based on their Exchange version, mailbox count, migration complexity, technical expertise, timeline, required features and budget.

Conclusion

An Exchange Server to Microsoft 365 migration should be treated as an infrastructure project, not a simple move of mailboxes. Before starting, IT administrators need to assess the Exchange setup, choose the migration method, check identity and network connectivity, review DNS and mail flow, test applications and devices, make sure permissions are correct, handle security and compliance rules, and run a pilot migration first.

Microsoft's own tools are a good fit for many companies. For organizations that want a guided way to move, Stellar Migrator for Exchange can be used as an alternative.

In the end, the best migration method is the one that causes the fewest problems for the business and gives a clear, safe and manageable path from an on-premises Exchange system to Microsoft 365.

Related: when the data itself is damaged

A migration moves what Exchange can read. If a user's mail lives in a corrupt PST, it has to be repaired before it can go anywhere. We tested Stellar's PST repair tools on a deliberately damaged file, both the desktop app and the free online service; the full write-up is in our Stellar Repair for Outlook review, and the video below shows the whole test.

If the Exchange database itself will not mount, our guide to mounting an Exchange database after a dirty shutdown with Eseutil covers that.