M365 Migration Playbook.

/ 01Pick the right license tier

Picking the wrong license up front is the single most common M365 mistake. Switching tiers later isn't fatal but it's expensive in time and licensing waste.

Pricing shown is current 2026 retail. Most CSPs (Cloud Solution Providers — including MSPs) sell at the same or slightly better rates.

Practical recommendation: Default to Business Premium for any business under 300 users that cares about security. The security stack alone (Defender for Office 365 + Intune + Azure AD P1) would cost $15-20/user/month to license separately, so the upgrade from Business Standard is essentially break-even and you stop having to bolt-on security tools.

/ 02Tenant setup & domains

Create the tenant with a permanent name

When you sign up for M365, Microsoft creates a tenant at yourcompany.onmicrosoft.com. You cannot rename this later. Pick the name you'd be willing to use as a fallback admin domain for the next decade. If you're "Acme Co.", consider acmeco.onmicrosoft.com, not acme-temp-2026.onmicrosoft.com.

Add your custom domain

In Microsoft 365 admin center → Setup → Domains → Add domain. You'll prove ownership via a TXT record. Then Microsoft generates the records you'll need: MX, SPF (Sender Policy Framework), Autodiscover, DKIM, and various Lync/Skype legacy records.

Don't switch DNS yet. Just verify ownership at this stage. You'll cut over DNS later, after mailboxes are populated.

Establish a "break-glass" admin account

Create one Global Administrator account that does NOT have MFA enforced (yes, really), with an extremely strong password stored in a physical safe. If MFA fails tenant-wide or all admins lose their phones, this account is your last resort. Document its existence; never use it for daily work.

Microsoft's official guidance: 2 break-glass accounts, exempted from Conditional Access, with monitored sign-in alerts. Use brk-glass-01@yourdomain.com and brk-glass-02@yourdomain.com patterns so they're identifiable in logs.

/ 03Choose your migration method

Three primary methods for moving existing mailboxes into M365:

Cutover migration

One-shot migration of all mailboxes at once. Works for fewer than 150 mailboxes. Source must be Exchange 2010 or later (or Exchange Online from another tenant). Mailboxes are copied to M365; on cutover day, DNS flips, and users start using M365.

Pros: Simple, fast, predictable. Cons: Brief outage window during cutover. No coexistence with on-prem during the migration period.

Staged migration

Migrate mailboxes in batches over time. Used for medium-large Exchange 2010 environments. Largely deprecated by hybrid migration in modern tenancies.

Hybrid migration

Establish coexistence between your on-prem Exchange and M365 using the Hybrid Configuration Wizard. Mailboxes can live in either location, with mail routing handled seamlessly. Migration happens mailbox-by-mailbox over weeks or months.

Pros: Zero-downtime user experience, granular control, fallback option. Cons: More complex setup, requires Exchange 2013+ on-prem, can be left in "permanent hybrid" state by accident.

Third-party migration tools

For sources Microsoft's native tools don't support (Google Workspace, IMAP-only systems, Lotus Notes, GroupWise, M365 tenant-to-tenant), use tools like BitTitan MigrationWiz, Quest On Demand Migration, SkyKick. Cost roughly $12-$25 per mailbox migrated.

What to actually pick

• Existing M365 / Exchange Online tenant → use BitTitan or Quest for tenant-to-tenant
• Existing Google Workspace → Microsoft's native Google Workspace migration tool
• On-prem Exchange 2013+ with under 150 mailboxes → cutover
• On-prem Exchange 2013+ with 150-2000 mailboxes → hybrid
• IMAP/POP-only system (cPanel hosting, etc.) → IMAP migration tool or third-party

/ 04Mailbox migration walkthrough

Example: cutover migration from on-prem Exchange or hosting provider IMAP for a 30-user SMB.

Pre-migration prep (1-2 weeks before)

1. Inventory existing mailboxes, sizes, distribution lists, shared mailboxes, calendar permissions, public folders
2. Note any size-of-mailbox outliers (mailbox over 50GB = special handling)
3. Decide on retention policies, archive policies, and litigation hold needs before mailbox data lands in M365
4. Communicate to users: timeline, what to expect, what won't work during cutover (phone client apps need reconfiguration; Outlook profiles need to be recreated)
5. Lower DNS TTLs on MX records to 300 seconds (5 minutes) at least 48 hours before cutover

Initial sync (5-10 days before cutover)

1. Create migration endpoint in M365 admin center → Exchange admin → Migration
2. Create migration batch, point at source server, provide admin credentials
3. Start the batch — first pass copies all mailbox data. For 30 typical mailboxes totaling 50GB, expect 18-36 hours.
4. The batch then keeps syncing incrementally — new mail in source gets copied to M365 within ~24 hours

Cutover day (typically a Friday evening or Saturday morning)

1. Final incremental sync completes
2. Change MX records to point at M365 (yourdomain-com.mail.protection.outlook.com)
3. Change Autodiscover CNAME to autodiscover.outlook.com
4. Update SPF record to include spf.protection.outlook.com
5. Enable DKIM in M365 Defender admin → policies → DKIM (generates CNAMEs, add to DNS)
6. Configure DMARC record (start with p=none, monitor for 4-6 weeks, then progress to p=quarantine then p=reject)
7. Complete the migration batch in M365 admin center
8. Reconfigure Outlook on each user's machine: remove old profile, create new profile pointing at M365 (Autodiscover handles it automatically once DNS propagates)
9. Reconfigure mobile devices: remove old account, add M365 account

Within 24 hours of cutover

1. Verify all users can send/receive in Outlook
2. Verify mobile devices working
3. Verify distribution lists and shared mailboxes accessible
4. Check Message Trace in Exchange admin for any rejected mail
5. Decommission old mail server (or schedule for 2-week post-migration retirement after final verification)

/ 05OneDrive & SharePoint migration

File migration is conceptually simpler than mailbox migration but operationally messier because of preserved file-share permissions.

OneDrive for personal files

Use Microsoft's OneDrive Sync client with Known Folder Move enabled. Configures Desktop, Documents, and Pictures on each user's PC to automatically sync to OneDrive. Deploy via Intune or GPO.

For migration of existing per-user files on a file server: use SharePoint Migration Tool (free) or third-party (MigrationWiz, ShareGate, AvePoint). Map source paths to OneDrive destinations. Preserves modified dates and basic metadata.

SharePoint for shared files

Each department typically gets a SharePoint site or a Microsoft Teams team (Teams creates a SharePoint site backend automatically). Map your existing shared drive structure to SharePoint sites:

Don't recreate your messy file server in SharePoint. A migration is the rare opportunity to rationalize your folder structure. Document the new structure before migrating, get sign-off from department leads, then migrate into the new structure rather than mirroring the old one.

Permissions

SharePoint permissions don't map perfectly from NTFS file-server ACLs. Plan to rebuild permissions cleanly using M365 groups (one group per team, group memberships drive access). Trying to preserve every individual user-level permission from a 10-year-old file server is a fool's errand.

/ 06Security baseline

Apply these immediately. Don't wait. Tenants without security baselines get compromised within weeks.

Identity

• Enable Security Defaults (free) OR Conditional Access (Business Premium+)
• Require MFA for all users, with Microsoft Authenticator preferred over SMS
• Block legacy authentication (POP, IMAP, SMTP AUTH without modern auth) — these bypass MFA
• Require admin accounts to use phishing-resistant MFA (FIDO2 hardware key or Windows Hello)
• Configure named locations and Conditional Access policies (e.g., block sign-in from countries you don't operate in)
• Set up break-glass admin accounts (covered above)
• Disable self-service password reset for admin accounts; enable for users with security questions OFF and MFA token-based reset

Email

• Enable DKIM in Defender → Policies → DKIM (generates two CNAMEs per domain)
• Configure SPF to include only authorized senders
• Configure DMARC (start at p=none with rua reporting to a monitored mailbox; tighten over 4-6 weeks)
• Enable Safe Attachments and Safe Links policies (Defender for Office 365 P1, included in Business Premium)
• Configure anti-phishing policies with impersonation protection for executive accounts
• Enable Mailbox Audit Logging (on by default in newer tenants but verify)
• Disable Outlook Forwarding rules to external addresses (a common attacker persistence mechanism)

Data protection

• Configure retention policies (e.g., retain all email 7 years, delete after)
• Configure DLP policies for obvious sensitive data (credit card numbers, SSNs, ePHI patterns)
• Set up sensitivity labels for documents (Confidential, Internal, Public)
• Enable Litigation Hold for any user under legal preservation

/ 07Intune device management

If you bought Business Premium or E3+, you have Intune. Use it. Unmanaged endpoints in a managed tenant are the weak link.

Enrollment

• Windows: Autopilot for new devices, or Azure AD join for existing
• macOS: Automated Device Enrollment via Apple Business Manager (free)
• iOS / iPadOS: ADE via Apple Business Manager, or user-driven enrollment
• Android: Android Enterprise (work profile or fully managed)

Baseline policies

• BitLocker enabled and key escrowed to Azure AD (Windows)
• FileVault enabled (macOS)
• Screen lock 5-10 minutes
• Minimum password complexity
• OS update compliance enforced
• EDR deployed to all endpoints (Defender for Endpoint or third-party)
• App allowlist / blocklist for company-owned devices
• Per-app VPN for sensitive apps if WFH

Compliance policies

Define what "compliant" means for each device type, then tie Conditional Access to require compliant devices for access to corporate resources. Now non-compliant device = no access. Forcing function.

/ 08Post-migration checklist

Two-week post-migration cleanup pass. Skip this and you'll have a beautiful migration that becomes a security incident in 90 days.

• ☐ Verify SPF, DKIM, DMARC are correct and DMARC is moving toward p=quarantine
• ☐ Disable all legacy authentication protocols
• ☐ Audit admin role assignments — should be minimal and named
• ☐ Run a Secure Score review (M365 Defender → Secure Score) and address top recommendations
• ☐ Verify backups of M365 data (M365 backup is your responsibility, not Microsoft's — use Veeam, Datto, Skykick, AvePoint, or similar)
• ☐ Decommission old mail server, file server, on-prem Exchange (after 30-day grace period)
• ☐ Update SaaS apps that authenticate against your old domain (SSO if applicable)
• ☐ Document the tenant: domains, admin accounts, license assignments, policies, third-party integrations
• ☐ Train users on Teams, SharePoint, OneDrive (not just "where's my email")
• ☐ Schedule quarterly review of Conditional Access policies and admin role assignments

A clean M365 migration with security baseline applied takes a typical SMB roughly 30-60 days of elapsed time. Skipping the baseline step or the post-migration cleanup is where most "we migrated to M365 and now everything's broken" stories come from.