Exchange to M365 Migration Checklist | EJK Consultancy

Moving from Exchange Server to Microsoft 365 is rarely just a mailbox move. Get it wrong and you are looking at lost mail, broken calendars and a Monday morning of angry phone calls. Get it right and users barely notice it happened. The difference is almost never the migration tool. It is the discovery work you do beforehand.

We have run enough of these to know that the projects that go sideways are the ones where someone thought discovery was optional. This checklist is the structure we use before touching a single mailbox. It is not a replacement for a proper project plan, but it will stop you missing the things that usually cause the pain. If you would rather have us run this for you, our Exchange to Microsoft 365 migration service starts with exactly this kind of review.

1. Confirm the current Exchange position

Before you choose a migration method, you need to know exactly what you are dealing with. Guessing here is how projects drift.

Check	Why it matters	Evidence to collect
Exchange version and CU level	Determines supported migration paths, how secure your setup actually is and upgrade requirements.	Exchange build number, installed CUs/SUs, Windows Server version.
Mailbox count and mailbox types	Migration approach changes depending on user, shared, room, equipment and archive mailboxes.	Mailbox inventory with size, item count, archive status and last logon.
Public folders	Public folders can extend project complexity if they are business-critical or heavily nested.	Folder hierarchy, size, permissions and owners.
Hybrid configuration	Existing hybrid objects or connectors can affect future mail flow and recipient management.	Hybrid Configuration Wizard output, connectors, organisation relationship.
Exchange management dependency	Some organisations keep Exchange only to manage attributes for synced users.	Directory sync status, recipient management process, server purpose.

2. Build a proper mailbox and recipient inventory

A mailbox inventory should be more than a list of users. This is where many projects drift, because the migration team discovers hidden dependencies too late. You need to identify large mailboxes, inactive mailboxes, litigation hold, retention requirements, delegated access, shared mailbox usage and mail-enabled groups before you move anything.

Export user mailboxes with size, archive status, hold status, last logon and primary SMTP address.
Export shared mailboxes and confirm business owners.
Export room and equipment mailboxes and note booking policies.
Review distribution groups, mail-enabled security groups and dynamic distribution groups.
Document mailbox permissions including Full Access, Send As and Send on Behalf.
Identify mailboxes using forwarding rules, external forwarding or mailbox-level transport settings.

Worth saying plainly: yes, someone in your organisation is probably forwarding email to a personal Gmail. Find them now, not after cutover when their messages start bouncing.

3. Review identity and directory synchronisation

Check	Why it matters	Evidence to collect
UPN alignment	Users should sign in with a predictable identity that matches their email where possible.	UPN export and proxyAddress review.
Entra Connect health	Directory synchronisation issues can block mailbox moves and licence assignment.	Sync status, last export, sync errors, connector health.
Duplicate or conflicting objects	Duplicate proxy addresses and unmanaged cloud users can stop migration batches.	IdFix or equivalent identity conflict report.
Admin and break-glass accounts	Privileged access must remain available during identity or Conditional Access changes.	Admin account list and emergency access process.
MFA and Conditional Access	Security controls should be planned before users move, not bolted on afterwards.	Current policies, exclusions, pilot groups and user impact notes.

4. Check mail flow before touching DNS

Mail flow is often where a clean technical migration becomes visible to the business. Before changing MX records, document every place email enters, leaves or relays through the environment.

Inbound MX path and any third-party filtering service.
Outbound smart host, connectors, journaling and disclaimers.
Line-of-business systems that send SMTP mail.
Multi-function printers, scanners and application servers.
SPF, DKIM and DMARC configuration.
Autodiscover records and internal SCP values.
Accepted domains, remote domains and transport rules.

Practical warning: do not assume SMTP relay is obvious. In many SMEs the real dependencies are printers, finance systems, CRM tools and old applications that silently relay through Exchange. We have seen organisations skip this step and end up chasing printer SMTP configs at 11pm on a Sunday. Find them before cutover.

5. Choose the migration approach

This is the decision that shapes the whole project. Our honest opinion: staged migrations are rarely worth the hassle anymore unless you are stuck on something ancient like Exchange 2010. Most SMEs are better served by a clean cutover or a minimal hybrid.

Approach	Best fit	Key considerations
Cutover	Smaller environments with simple requirements and limited coexistence needs.	Requires a clean weekend cutover plan, strong communications and quick post-migration support.
Staged	Older Exchange environments where batches are required.	Less common now, but still relevant in some legacy scenarios.
Minimal hybrid	Medium environments wanting a controlled move without full long-term coexistence.	Useful where directory sync and batch migration are required.
Full hybrid	Larger or complex organisations needing coexistence, free/busy, centralised mail flow or staged migration over time.	More moving parts, but better control for complex environments.

Microsoft lay out the options in their guidance on ways to migrate multiple email accounts, and their mail migration advisor is a decent starting point if you want to sanity-check your choice.

6. Run a technical pilot

Never migrate everyone at once without proving the process on a small group first. This is the step that separates a smooth migration from a Monday morning of angry phone calls.

Select pilot users from different departments and device types.
Include one executive assistant or delegated mailbox scenario if applicable.
Validate Outlook, mobile, webmail, calendar sharing, Teams calendar and shared mailbox access.
Confirm external mail flow, internal mail flow and mail from line-of-business systems.
Record user issues and update the migration runbook before wider migration.

7. Cutover and post-migration validation

Check	Why it matters	Evidence to collect
DNS cutover	MX, Autodiscover and SPF changes need to be controlled and tested.	Before and after DNS record screenshots or export.
Migration batch completion	Completed status alone is not enough; failed and skipped items need review.	Batch reports and skipped item summary.
Outlook and mobile access	Users judge the project by first-day experience.	Pilot validation and service desk issue log.
Delegated access	Shared mailboxes, calendars and delegates must continue to work.	Test cases for key shared mailboxes.
Legacy Exchange role	Decide whether Exchange remains for management, hybrid or retirement.	Decommission plan or management-only plan.

Common mistakes to avoid

Migrating every mailbox without cleaning up inactive users first.
Forgetting SMTP relay and application mail dependencies.
Changing DNS without a rollback and validation plan.
Ignoring mailbox permissions until users complain.
Treating SharePoint, Teams and OneDrive adoption as separate from the email migration.
Leaving old Exchange servers in an unknown state after migration.

That last point trips people up. An old Exchange server left running "just in case" becomes an unpatched liability surprisingly quickly. Decide its fate and write it down.

Book a Migration Readiness Assessment

Planning an Exchange or Microsoft 365 migration? We can review your current environment and give you a clear migration plan before any changes are made.

Book a Migration Readiness Assessment