The Complete Microsoft 365 Migration Guide & Checklist (2025)

Before you migrate a single mailbox, you need to understand what you are moving and how the data will behave. A migration, by its very nature, creates conditions where data can be temporarily islanded. Some tools can lift and shift data quickly — but faster is not always better. This guide covers the planning decisions, the environment preparation, the execution checklist, and the post-migration items that will determine whether your Microsoft 365 migration is a weekend success or a months-long cleanup project.

What Type of Microsoft 365 Migration Is Right for Your Organization?

The migration type you choose shapes every downstream decision: tool selection, timeline, coexistence strategy, and risk profile. There is no universally correct answer — the right type depends on your user count, data footprint, compliance requirements, and tolerance for disruption.

Quick Lift and Shift (Cutover Migration)

Best suited for organizations with 500 to 1,500 mailboxes and a manageable data footprint. Third-party tooling (BitTitan MigrationWiz, SkyKick, Movebot) can run the data migration during business hours and stage a cutover — typically over a weekend — with minimal mail flow interruption. These projects generally run 3–4 weeks from kickoff to go-live.

This is our preferred approach when it's available. It is fast, has a clear cutover moment, and produces the cleanest post-migration environment. The key constraint is size: above roughly 1,500 mailboxes, the cutover window becomes risky without a more staged approach.

Staged Lift and Shift

A hybrid of tooling-based speed and phased execution, suited to 2,000–5,000 users. Migrated users can access their cloud mailboxes and begin testing during the migration period, though some application integrations may not be testable end-to-end until cutover. Expect a project duration of 4–10 weeks.

Staged migrations require careful coexistence planning — particularly around shared mailboxes, distribution groups, and calendar objects that span both environments during the transition period.

Hybrid Exchange

For organizations with 2,500 to 10,000+ users, complex requirements, or special constraints (EHR/EMR integrations, litigation holds, regulatory holds, or multi-forest environments), Hybrid Exchange is the appropriate model. A Hybrid Configuration Wizard (HCW) establishes a secure mail flow connection between on-premises Exchange and Exchange Online, maintaining full calendar coexistence, free/busy lookups, and unified GAL while mailboxes are migrated in waves.

Hybrid projects typically span 6 weeks to 3 months depending on organization size, data volume, and complexity of integrations being maintained during the migration window.

Modern Hybrid (2024+)

Microsoft now offers Modern Hybrid (also called "Minimal Hybrid") for organizations that want Entra ID integration and single sign-on without the full operational burden of a traditional hybrid deployment. This is particularly useful for smaller organizations doing a phased migration who need free/busy coexistence but can't justify a full hybrid server. Evaluate this option before committing to classic Hybrid Exchange.

What Else Do You Need to Plan Before Migrating to Microsoft 365?

What Is a UPN and Why Does It Matter?

The User Principal Name (UPN) is the on-premises Active Directory login attribute in the format username@domain.com. In most Microsoft 365 environments, the UPN becomes the user's sign-in name — and ideally, it matches their primary SMTP email address. This matters because it creates a consistent login experience: users sign into Microsoft 365 with what feels like their email address rather than a legacy domain login.

Changing the UPN does not change the sAMAccountName — the legacy NetBIOS login (DOMAIN\username). Workstation logins are unaffected unless users are explicitly logging in with UPN format.

The biggest risk when changing UPNs is third-party application dependencies. Audit every application that authenticates against Active Directory before you touch UPNs. In healthcare environments, this commonly includes MEDITECH, Epic, Cerner, and various clinical systems. Map your dependencies carefully — some of these systems will need configuration updates to continue functioning after UPN changes.

Changing the UPN

The mechanics are straightforward: write the user's mail attribute value to the userPrincipalName attribute. In most environments this is done via PowerShell at scale. Apply the principle of minimum necessary change — only update UPNs for accounts that will be signing into Microsoft 365. Leave service accounts, shared accounts, and non-migrating accounts untouched.

A sample PowerShell approach:

Always run in report-only mode first. Test against a pilot group before touching production.

What If We Can't Change the UPN?

Some environments have application dependencies or compliance constraints that make UPN changes impractical. If that's the case, users will need to understand their UPN and use it as their Microsoft 365 sign-in — even though the sign-in prompt says "email address." This is a user education and change management problem as much as a technical one. Consider adding the UPN as an alternate email address (secondary proxy address) on each user's account to reduce confusion. It won't fix the login, but it reduces errors when users respond to sign-in prompts expecting email-based input.

But My Active Directory Forest Is "company.local"

This is still one of the most common issues we encounter — particularly in organizations that built their AD infrastructure in the Windows Server 2003 era. Non-routable internal domains (.local, .lan, .internal) cannot be used as UPN suffixes for Microsoft 365 because Microsoft 365 requires a publicly verified domain.

The fix is to add a UPN suffix to your Active Directory forest. This is non-destructive — you're adding an option, not changing any accounts yet. In Active Directory Domains and Trusts, right-click the root node, choose Properties, and add your routable domain (e.g., company.com) as an alternative UPN suffix. Then update user UPNs to use the new suffix. Microsoft documents this process in KB243629.

If you have another AD forest in your environment that already uses the suffix you're trying to add, escalate to a senior architect — that becomes a more nuanced conversation involving forest trust configuration.

What Is Microsoft Entra Connect and What Does It Do? formerly Azure AD Connect

Microsoft Entra Connect is the on-premises synchronization service that bridges your local Active Directory and Microsoft Entra ID (the identity backend for Microsoft 365). It synchronizes user accounts, groups, and attributes — password hashes or pass-through authentication tokens — from your AD forest into Entra ID, allowing users to sign into Microsoft 365 with their on-premises credentials.

Entra Connect is typically installed on a domain-joined member server (not a domain controller). It runs as a service and syncs on a scheduled cycle (default 30 minutes). Key decisions at install time include:

• Password Hash Sync (PHS) — hashes are synchronized to Entra ID; authentication happens in the cloud. Simplest, most resilient option and now recommended by Microsoft for most environments.
• Pass-Through Authentication (PTA) — authentication requests are passed back to on-premises AD. Requires on-premises infrastructure availability for sign-in.
• Federation (AD FS) — full federation via Active Directory Federation Services. Adds significant complexity and infrastructure overhead; generally only justified for specific compliance or security requirements.

Pre-Check: Licenses and Users

Your plan has to start with licenses and users. Nothing moves until you know exactly what you have and what you're paying for.

1. Servers and Licenses — Identify who is being migrated and what Microsoft 365 license SKU each user will receive. Licenses must be procured and assigned before mailboxes can be created in Exchange Online. Validate your license counts against actual user counts — there should be no gap on cutover day.
2. Public Folders — Public folders count as migration mailboxes. Get a complete inventory: folder hierarchy, size, permissions, and the target state (migrated as public folders, converted to shared mailboxes, or deprecated). Every folder that migrates needs to be explicitly listed and scoped.
3. Shared Mailboxes — In Microsoft 365, shared mailboxes do not require a license unless they exceed 50GB or need specific add-on features (archiving, litigation hold). However, they still count as migrated objects and must be listed and planned for individually.
4. Distribution Groups and Mail-Enabled Security Groups — Every group needs to be accounted for. Know which are managed on-premises via AD sync vs. which will be managed directly in Exchange Online post-migration.
5. Shared Calendars and Room/Resource Mailboxes — This is a critical coexistence issue. If a shared calendar has users on both on-premises and Exchange Online during a staged migration, free/busy lookups will break unless you're running Hybrid. Map every shared calendar and plan when its owner mailbox migrates relative to its delegates.

What Is the Pre-Migration Checklist for Microsoft 365?

A major function of Phase 1 is collecting facts and figures about the existing environment. You cannot plan what you don't know.

1. Exchange Server inventory — What version of Exchange is running? What roles? Are all Exchange servers on supported versions? Exchange 2010 and 2013 are end-of-life; if these are in your environment, plan their decommission as part of — or immediately following — the migration.
2. Desktop and Microsoft 365 app compatibility — What version of Office is the client running? Microsoft 365 Apps for Enterprise (formerly Office 365 ProPlus) is required for full functionality with Exchange Online. Clients on Office 2016 or earlier will have limited feature support and will need to be updated pre- or post-migration.
3. UPN alignment — Document your decision on UPN suffix (see above). Who needs UPNs changed? What's the process? What app dependencies exist?
4. Network architecture and DNS — Document MX records, autodiscover records, SPF, DKIM, and DMARC configuration. Identify any split-brain DNS or non-standard mail routing. Non-routable AD domains need UPN suffix additions.
5. Authentication and MFA strategy — Are you deploying MFA? What method — Microsoft Authenticator, FIDO2 passkeys, hardware tokens? Are there federation services currently in play (AD FS, Okta, Ping)? Plan MFA rollout as part of the migration, not an afterthought.
6. Conditional Access policies — Define your Conditional Access baseline before migration. At minimum: require MFA for all users, block legacy authentication (Basic Auth was retired by Microsoft in October 2022 — if any clients are still using it, they need to be addressed before migration), and configure compliant device requirements if Intune is in scope.
7. Directory design and AD health — Any AD replication issues, stale objects, or duplicate accounts will become migration problems. Run IDFix or Microsoft Entra Connect's built-in readiness checks against your directory before you begin. Address issues before you sync.
8. Bandwidth assessment — Migration velocity is directly constrained by available bandwidth. Run a bandwidth assessment and determine whether you need to throttle migration tools or schedule migrations off-hours. Staging migrations in waves is often necessary in bandwidth-constrained environments.
9. Email security appliances — If mail flows through a third-party gateway (Mimecast, Barracuda, Cisco IronPort), document the mail flow path and plan cutover of MX records and connector configuration. These appliances also need DKIM, SPF, DMARC, and ARC signing configuration updated to reflect the new environment.
10. Certificates — Identify any certificates required for Exchange hybrid, federation, or mail connectors. Note expiration dates. Ensure certificates are procured and staged before they're needed.
11. Client applications and platforms — Document non-Windows mail clients: Mac Outlook, iOS/Android native mail, third-party clients. Ensure Exchange Online connectivity (IMAP/EWS) and modern auth (OAuth 2.0) is compatible with each.
12. Legacy authentication audit — With Basic Auth retired across Microsoft 365 as of October 2022, audit for any remaining clients or applications using legacy protocols (RPC over HTTP, EWS with basic auth, SMTP AUTH with username/password). These need to be remediated before or during migration.
13. Compliance and archiving requirements — Document any eDiscovery, litigation hold, retention policy, or regulatory compliance requirements. These drive licensing decisions (E3 vs. E5, Exchange Online Archiving add-on) and need to be addressed in the Microsoft Purview configuration during migration.
14. Microsoft Defender for Office 365 planning formerly ATP — Which Defender for Office 365 plan is included in your licensed SKU? Plan Safe Links, Safe Attachments, anti-phishing policies, and outbound spam policies as part of the migration configuration — not as a post-migration cleanup item.
15. Microsoft Purview Information Protection planning formerly AIP — If information protection, DLP, sensitivity labels, or message encryption are in scope, design these policies before migration. Retroactively applying DLP and labels to a live environment is harder than building the framework at cutover.
16. Mobile device strategy — Document mobile platforms in use. Plan Intune MDM/MAM enrollment, conditional access for mobile devices, and Autopilot provisioning if applicable. ActiveSync device partnerships will need to be re-established post-cutover for users who don't use Outlook Mobile.
17. Intune and endpoint management scope — If Intune is in scope, plan Intune enrollment, device compliance policies, and app protection policies as part of the migration. Don't treat endpoint management as a separate post-migration initiative — it's most efficiently deployed during the migration window when users are already experiencing change.
18. Copilot for Microsoft 365 planning — If Copilot for Microsoft 365 licenses are in scope, note that Copilot requires users to be on Exchange Online (not hybrid) and requires specific SharePoint and Teams configurations. Plan this as a post-migration activation item, not a day-one deliverable.
19. Communications and change management plan — Simple email notifications are not enough. Build a structured communication plan: announcement, pre-migration checklist for users, cutover notification, and post-migration support resources. User adoption failure is one of the top causes of perceived migration failure.

Phase 2 — Prepare the Environment

1. Add and verify your domain — Add your domain(s) to the Microsoft 365 admin center and complete DNS verification. Create DNS records (TXT verification, then MX, Autodiscover, SPF) per Microsoft's guidance.
2. Active Directory cleanup — Run Microsoft Entra Connect's IdFix tool against your directory. Resolve duplicate proxy addresses, invalid UPN formats, missing attributes, and objects that will fail sync. Address issues before you install Entra Connect, not after.
3. Add UPN suffixes and update user UPNs — Add routable UPN suffixes to the AD forest. Update user UPNs as documented in Phase 1. Validate with a pilot group before bulk updates.
4. Install Microsoft Entra Connect — Install Entra Connect on a dedicated member server. Select your sync method (PHS recommended for most environments). Run the initial sync and validate that all expected objects appear correctly in Entra ID. Alternatively, evaluate Entra Connect Cloud Sync for simpler environments.
5. Configure Exchange Hybrid (if applicable) — Run the Hybrid Configuration Wizard (HCW). Validate OAuth, free/busy, and mail flow between on-premises and Exchange Online. Test calendar coexistence with pilot users before migrating any mailboxes.
6. Configure MX and mail flow — Plan whether MX records will point to Exchange Online Protection or continue to flow through an on-premises gateway or third-party appliance during the migration period. Document the final target state and the cutover plan.
7. Configure Entra ID and Conditional Access baseline — Set up your Conditional Access policies, named locations, MFA registration campaign, and SSPR (Self-Service Password Reset) before migrating users. Users should be able to register for MFA from day one on M365.
8. Block legacy authentication — Create a Conditional Access policy to block legacy authentication protocols. Test against pilot users first. Monitor sign-in logs for any legacy auth usage before enforcing broadly.
9. Configure SharePoint Online and OneDrive — If SharePoint Online and OneDrive for Business are in scope, configure information barriers, sharing settings, external sharing policies, and storage limits before migrating content. Enable Known Folder Move (KFM) for OneDrive via Intune or Group Policy.
10. Configure Microsoft Teams — Teams is the platform for IM, conferencing, and collaboration in Microsoft 365 (Skype for Business is end-of-life). Configure Teams policies, meeting settings, external access, and guest access as part of the migration. Calendar events from Skype for Business or Lync meeting links will not work in the destination environment and will need to be recreated.
11. Deploy and validate client applications — Push Microsoft 365 Apps for Enterprise via Intune or SCCM/Configuration Manager. Validate that Outlook, Teams, OneDrive sync client, and other required apps are installed and configured on a pilot device set before broad deployment.

What Happens During a Microsoft 365 Migration?

1. Data cleanup campaign — Before migration begins, run a user-facing cleanup campaign. The less data that migrates, the faster the migration and the cleaner the destination. Have department leads audit mailboxes and archive or delete stale content. This is easier to enforce before migration than after.
2. Assign Microsoft 365 licenses — Assign licenses to all migrating users via the Microsoft 365 admin center or PowerShell bulk assignment. Users must have licenses before their mailboxes can be provisioned in Exchange Online.
3. Run pilot migration — Migrate 5–20 pilot users first. Validate mail flow, calendar coexistence, mobile device connectivity, client applications, MFA, and Conditional Access. Resolve issues discovered in the pilot before migrating production waves.
4. Execute migration waves — Migrate users in batches sized to your bandwidth and support capacity. Use your migration tool's throttling settings to avoid saturating the link. Monitor migration progress actively — don't batch-and-ignore.
5. Validate each wave — After each batch, have migrated users validate: email send/receive, calendar access, contact sync, mobile device connectivity, and access to shared mailboxes and calendars.
6. Migrate public folders — Migrate public folders per your pre-defined inventory. Validate permissions post-migration. Convert any folders being repurposed as shared mailboxes or Teams channels.
7. Configure email signatures — Email signatures don't migrate. Deploy signatures via Exclaimer, CodeTwo, or Exchange Online transport rules. Coordinate with marketing/communications on template standards.
8. Cut over MX records — After all mailboxes are migrated, update MX records at your domain registrar to point to Exchange Online (or your third-party gateway, updated to relay to Exchange Online). Allow for DNS TTL propagation. Monitor mail flow immediately post-cutover.
9. Configure mobile devices — Update mobile Outlook profiles (modern auth, not ActiveSync with username/password). Remove and re-add accounts on devices that don't automatically reconfigure. Enforce Intune compliance policies.
10. Enable Microsoft Defender for Office 365 policies — Activate Safe Links, Safe Attachments, anti-phishing, and outbound spam policies. Review the default preset security policies and tune for your organization's risk tolerance.
11. Enable Microsoft Purview policies — Activate sensitivity labels, DLP policies, retention policies, and information barriers per your Phase 1 design. Validate with test documents and emails before enforcing in block mode.
12. Enable MFA for all users — This should be done as early as possible in the migration. Use Conditional Access to enforce MFA registration. Enable the MFA registration campaign in Entra ID to prompt users at next sign-in.
13. Full-scale post-migration testing — Test all business-critical scenarios: mail flow, calendar, contacts, shared mailboxes, distribution groups, room/resource booking, external sharing, Teams meetings, mobile access, and any third-party integrations. Don't close out the project until every item on your test plan is validated.
14. Decommission on-premises Exchange — After all data is validated in Exchange Online and mail flow is confirmed, decommission on-premises Exchange servers per Microsoft's documented decommission process. Do not simply shut down Exchange servers — improper decommission leaves residual schema attributes that can complicate future directory operations. Follow the official retirement process.

What Cannot Be Migrated to Microsoft 365?

Every migration plan needs a "cannot migrate" section. These are items that tooling will not carry across — some require user action, some require administrative remediation, and some are simply lost if not documented and handled before cutover.

1. Email forwarding rules — Microsoft disables external email forwarding at the tenant level by default for security reasons (to prevent exfiltration via compromised accounts). Forwarding that existed on-premises will be turned off. Review all forwarding requirements and re-implement through Exchange Online's outbound connector or documented exceptions with appropriate approval.
2. Certain calendar notifications — Meeting invitations and cancellation notices sent before migration may not render correctly for recipients in the destination environment.
3. Calendar permissions — Calendar sharing permissions typically do not migrate unless the source and destination UPN prefixes match exactly. Plan for users to re-share calendars post-migration. Communicate this to affected users before cutover.
4. Exceptions to recurring meetings — If a user has modified a specific instance of a recurring meeting (changed time, removed attendees, updated description for that occurrence only), those exceptions often do not migrate. Affected users will need to recreate them.
5. Meeting acceptance status — Recently sent invitations and their response status (accepted/declined/tentative) may not transfer.
6. Items with type mismatches — An item stored in a folder of the wrong type (e.g., a calendar response in a mail folder) will not be visible at the destination. These exist in some legacy environments due to Outlook version changes over the years.
7. Modified recurring meeting exceptions — Modified description text and modified attendee lists for individual exceptions to recurring meetings do not migrate reliably.
8. Custom Contact fields and Business Card photos — User-defined fields added to Contacts and photos added via the Outlook Business Card view do not migrate.
9. Personal Distribution Lists / Contact Groups — Outlook-local contact groups (not AD-backed distribution groups) do not migrate with the mailbox. Users should export these before cutover and re-import if needed.
10. RSS feeds — RSS feed subscriptions configured in Outlook are not migrated.
11. Mailbox sharing settings, aliases, and client-side delegates — Delegate access configured client-side in Outlook (not via Exchange admin) needs to be verified and potentially reconfigured post-migration. Aliases on the on-premises mailbox must be mirrored as proxy addresses in Exchange Online.
12. Personal MRM (Retention) tags — User-applied personal retention tags do not migrate and must be recreated in Microsoft Purview compliance policies.
13. Color categories — Category color assignments do not migrate. Users will need to re-assign colors to existing categories post-migration.
14. Teams and Skype for Business meeting links — Teams meeting links are tied to the source tenant. Any meeting links generated in an on-premises Skype for Business or Lync environment will not function in Exchange Online / Teams. These meetings need to be recreated. Note: Skype for Business Online reached end-of-life in July 2021. Microsoft Teams is the platform. If you're still running on-premises Skype for Business, plan its migration as part of this project.
15. Encrypted emails (S/MIME, PGP, third-party encryption) — Emails encrypted with S/MIME certificates, PGP, or third-party encryption tools cannot be migrated in their encrypted form. They must be decrypted before migration or remain accessible only in the source environment. Plan for this with your compliance and security teams.
16. Inbox rules — Client-side inbox rules do not always migrate reliably. For users with complex rule sets, have them export rules from Outlook before migration (File → Manage Rules & Alerts → Options → Export Rules) and re-import after cutover. For server-side rules, test your specific tooling's behavior.

Microsoft 365 Licensing Reference

Licensing in Microsoft 365 has evolved significantly. The following is a current-as-of-2025 reference. Always verify current pricing and features at Microsoft's licensing portal, as Microsoft revises SKU contents regularly.

Microsoft 365 Business Plans (1–300 users)

• Microsoft 365 Business Basic — Web and mobile apps only; no desktop Office apps. Exchange Online (50GB mailbox), Teams, SharePoint, OneDrive (1TB). Good for light users or secondary accounts.
• Microsoft 365 Business Standard — Includes desktop Office apps (Word, Excel, PowerPoint, Outlook, Teams). 1TB OneDrive. Suitable for most business users.
• Microsoft 365 Business Premium — Adds Intune device management, Microsoft Defender for Business, Entra ID P1, Azure Information Protection P1, and advanced security features. Recommended for SMB environments where the security tooling justifies the cost delta.

Microsoft 365 Enterprise Plans

• Microsoft 365 E3 — Full desktop apps, 100GB Exchange mailbox, unlimited archive (after activation), SharePoint Online unlimited storage, Teams, OneDrive 1TB+. Includes Microsoft Purview compliance (eDiscovery, retention, DLP), Azure Information Protection P1, and Entra ID P1. Standard enterprise baseline.
• Microsoft 365 E5 — Everything in E3 plus Microsoft Defender for Office 365 Plan 2, Defender for Endpoint P2, Entra ID P2 (PIM, Privileged Access Management, Identity Protection), Microsoft Purview E5 compliance, Power BI Pro, and Phone System. The full security and compliance stack. Required for organizations with advanced threat protection, insider risk, or eDiscovery requirements.
• Microsoft 365 F3 (Frontline) — Designed for shift workers and frontline employees who primarily use mobile or shared devices. Web/mobile apps only, 2GB Exchange mailbox. Significantly lower cost than E-series plans.

Exchange Online Standalone Plans

• Exchange Online Plan 1 — 50GB mailbox, Exchange Online Protection anti-spam, no in-place archive. Suitable for basic email-only users where Microsoft 365 collaboration features aren't needed.
• Exchange Online Plan 2 — Unlimited mailbox and unlimited archive, litigation hold, in-place eDiscovery. For users with archiving or compliance requirements who don't need the full M365 suite.

Exchange Online Archiving Add-On

For users on Exchange Online Plan 1 or Microsoft 365 Business plans who need an in-place archive, the Exchange Online Archiving add-on provides an unlimited archive mailbox, in-place hold, and retention policies. This is frequently required in healthcare and financial services environments for regulatory retention compliance.