M365 Migrations: The Checklist I Use Every Time

Moving clients to Microsoft 365 is one of the most common projects in managed IT services. After dozens of migrations across different industries and org sizes, I've built a checklist that prevents the mistakes that turn a weekend project into a week-long firefight.

Pre-Migration Discovery

Before touching anything, document the current state:

Current Mail System

• Mail server type (Exchange on-prem, hosted Exchange, Google Workspace, IMAP/POP)
• Total mailbox count and sizes
• Shared mailboxes, distribution lists, mail-enabled groups
• Any mail flow rules or transport rules
• Journaling or compliance requirements
• Third-party spam filtering in place

DNS and Domain

• Current registrar and DNS host
• All MX, SPF, DKIM, DMARC records
• Autodiscover records
• Any custom DNS entries tied to mail

Client Environment

• Outlook versions in use
• Mobile devices connecting to mail
• Applications sending mail (scanners, LOB apps, CRM systems)
• Calendar integrations

Licensing and Tenant Setup

Choose the right license tier:

• Business Basic: Web/mobile apps, 50GB mailbox
• Business Standard: Desktop apps, same mailbox
• Business Premium: Adds Defender, Intune, Azure AD P1
• E3/E5: Enterprise features, larger mailboxes, compliance tools

For most SMBs, Business Premium hits the sweet spot. Security features justify the cost increase over Standard.

Tenant configuration before adding users:

• Set default domain
• Configure tenant-wide MFA (Security Defaults at minimum, Conditional Access preferred)
• Set password policies
• Configure external sharing settings in SharePoint/OneDrive
• Set up admin accounts with strong, unique passwords

The Migration Itself

DNS Preparation (Do This First)

Lower TTL values 24-48 hours before migration:

MX record: Lower to 300 seconds
Autodiscover: Lower to 300 seconds
SPF: Lower to 300 seconds

This ensures DNS changes propagate quickly when you cut over.

Create Users and Assign Licenses

I prefer creating users before migration starts:

1. Create all users in M365 admin center
2. Assign appropriate licenses
3. Set temporary passwords
4. Do NOT change MX records yet

Migration Method Selection

Cutover Migration (Exchange/IMAP < 150 mailboxes)

• Best for small orgs
• All mailboxes move at once
• Minimal hybrid complexity

Staged Migration (Exchange 2003/2007)

• Batches of users over time
• Requires directory sync
• More complex but less risky

Hybrid (Exchange 2010+)

• Coexistence between on-prem and cloud
• Users can be moved individually
• Best for larger orgs or extended timelines

IMAP Migration

• Works for any IMAP source
• Mail only (no calendar/contacts)
• Manual or third-party tool for calendar/contacts

For Exchange Cutover (Most Common SMB Scenario)

1. Verify on-prem Exchange has valid SSL cert
2. Create migration endpoint in M365
3. Create migration batch
4. Let initial sync complete (this can take hours/days depending on data)
5. Schedule final sync and cutover during maintenance window

Cutover Night Checklist

Execute in order:

1. Final sync - Trigger incremental sync to catch recent changes
2. Stop inbound mail flow - Point MX to a temporary holding or just proceed quickly
3. Complete migration batch - Finalize in M365
4. Update DNS records:

   MX: point to tenant.mail.protection.outlook.com (priority 0)
   Autodiscover: CNAME to autodiscover.outlook.com
   SPF: v=spf1 include:spf.protection.outlook.com -all
   DKIM: Enable in M365 and add CNAME records
   DMARC: Add or update policy

5. Verify mail flow - Send test emails in both directions
6. Configure Outlook on workstations - New profile or reconfigure existing
7. Mobile device reconfiguration - Remove old account, add new
8. Test send-as and shared mailboxes

Post-Migration Tasks

Within First 24 Hours

• Verify all users can send and receive
• Check shared mailbox access
• Confirm calendar sharing works
• Test room/resource booking
• Verify distribution list delivery
• Check mail flow rules are working

First Week

• Configure email signatures (if centrally managed)
• Set up any needed transport rules
• Configure archiving/retention policies
• Enable litigation hold if required
• Set up DLP policies if needed
• Train users on OneDrive sync

Ongoing

• Monitor mail flow reports for delivery issues
• Check quarantine regularly until users learn
• Review sign-in logs for MFA adoption
• Gradually roll out additional features

Application Mail Configuration

This is where migrations often break down. Every device and application that sends mail needs reconfiguration.

Scanners/Copiers:

• SMTP relay through M365 (requires authentication)
• Or set up SMTP relay connector for internal devices
• Document: IP ranges, sender addresses

LOB Applications:

• May need app password if using legacy auth
• Better: Configure for modern auth if supported
• Or: Send via authenticated SMTP

SMTP Relay Options:

Direct Send (simplest for internal):

Server: tenant-com.mail.protection.outlook.com
Port: 25
TLS: Required
Auth: None (but requires static IP and connector)

SMTP Client Submission (most compatible):

Server: smtp.office365.com
Port: 587
TLS: Required
Auth: Licensed user credentials

Common Gotchas

• Autodiscover failures: Old autodiscover records pointing to on-prem cause Outlook to try connecting to the old server. Verify autodiscover CNAME is correct and propagated.
• Mobile devices stuck: Some devices cache old server settings aggressively. Full account removal and re-add is often faster than troubleshooting.
• SPF failures: If you're also using a third-party email service (marketing, CRM), make sure SPF includes all senders. You only get one SPF record, so combine them.
• Shared mailbox licensing: Shared mailboxes don't need licenses unless they need their own archive or are over 50GB. Don't over-license.
• Calendar delegation breaks: If users had delegate access to calendars, this needs to be reconfigured in M365. It doesn't always migrate cleanly.
• Mail forwarding: External forwarding is disabled by default in M365. If users were forwarding to personal accounts, they'll complain. Decide if you want to enable this (security consideration).

My Preferred Timeline

• Week -2: Discovery, licensing decisions, tenant prep
• Week -1: User creation, initial sync started, lower DNS TTL
• Migration weekend: Cutover Friday night or Saturday morning
• Week +1: Aggressive monitoring, workstation configs, user support
• Week +2: Application reconfigs, cleanup old environment
• Month +1: Decommission old mail system

This timeline assumes a straightforward cutover. Hybrid deployments need longer runway.

Tools I Use

• BitTitan MigrationWiz: When native tools are too slow or limited
• DNS Checker sites: Verify propagation before declaring victory
• Message Header Analyzer: Troubleshoot delivery issues
• M365 Admin Center: The obvious one, but the message trace feature is invaluable

The key to smooth migrations is preparation. Every migration that went sideways happened because something wasn't documented or discovered beforehand. Take the time upfront, and the actual cutover becomes almost boring. That's the goal.