Microsoft Office 365 Migration: A Step-by-Step Checklist

Key Takeaways

• A Microsoft 365 migration touches email, files, identity, permissions, and compliance policies. Skipping any of these creates gaps that show up during audits, ediscovery requests, or user support tickets.
• Start with clear goals, a complete environment inventory, and a cleanup plan so you don’t move stale, duplicate, or non-compliant data into the new tenant.
• Choose the migration method based on your source system, mailbox count, timeline, and coexistence requirements, then plan for Microsoft throttling and staged batch moves.
• Validate mail flow, permissions, DNS, Outlook connectivity, and data completeness after cutover before decommissioning the source environment.
• If your organization must meet HIPAA, SEC 17a-4, FINRA, FOIA, or similar requirements, make compliance coverage part of the migration plan from day one.

Introduction

A poorly planned Microsoft 365 migration can stall productivity for weeks, break retention policies, and leave compliance gaps that surface during the next audit. Most organizations underestimate the scope of what needs to move, and the result is missed mailboxes, broken permissions, and frustrated users.

Whether you’re migrating from on-premises Exchange or another email platform, the work goes beyond mailbox transfers. You need a clear plan for identity, data cleanup, user rollout, post-migration testing, and compliance coverage before you decommission the source environment.

In this guide, you’ll learn:

• How to define practical migration goals and get stakeholder sign-off
• What to include in your Microsoft 365 migration checklist and environment inventory
• How to compare migration methods and plan for workload-specific moves
• Which risks commonly delay migrations and how to reduce them
• How to maintain compliance before, during, and after migration

Before committing to the migration process, Microsoft recommends setting your goals, as they will inform the decisions you’ll take during the process.

How to Define Your Microsoft 365 Migration Steps and Goals

Regardless of the company’s size, the first concern with the Microsoft 365 migration is the impact on daily business operations. The first goal is to minimize disruption by carefully planning the migration process.

The other goal to keep in mind is setting a timeframe and committing to delivery due dates. Not only will a firm, clear timeline ensure the success of the migration, but it will also positively affect employees as you will meet their expectations when it comes to changes.

Set goals that are specific enough to measure. For example, you might aim to complete mailbox migration for all 500 users within 30 days with zero data loss, maintain uninterrupted legal hold coverage throughout the migration window, or achieve 95% user adoption of Outlook and Teams within two weeks of cutover.

Before work begins, make sure IT, Legal, Compliance, and HR departments review and sign off on the migration goals. If your organization operates in a regulated industry, include a compliance readiness goal as well, such as confirming that retention policies are active in the destination environment before decommissioning the source.

Your Microsoft Office 365 Migration Checklist

Although Microsoft has provided their users with a great deal of help with the transition posters, tips, and tricks, it’s helpful to go through the takeaways. Here are the most important steps to include in your Microsoft 365 migration checklist.

Step 1: Communicate the Microsoft Office 365 migration plan to your team

Before doing anything else from the migration checklist, ensure that you prepare your workforce — let them know about the process and prepare them for the upcoming steps. Employees will play a role in the process as part of the next step, and it’s helpful that they know about it so that they can manage their expectations and stay on track with the timeline.

Microsoft’s FastTrack program for Microsoft 365 migration is designed to help you transition, including employee participation, as explained in the next step.

Step 2: Create a full environment inventory

As per Microsoft’s recommendation, you should list everything in your environment, including:

• User accounts — Employee email addresses and login credentials (including former employees)
• Mailboxes — Make sure to include all mailboxes, together with their number and size
• Storage details — The locations of file shares
• Client data — Versions, configurations, and specifications, including OS, browsers, and applications
• Communication platforms — Collaboration systems and IM systems
• Network settings — Proxy and firewall settings, DNS hosts, etc.
• All application details that you’ve integrated — CRM, HR apps, mail-enabled apps, etc.
• Retention policies and legal holds — Map these before migration so compliance coverage is not broken in the destination environment
• PST files and local archives — Identify historical data stores that will not migrate automatically
• Data volume estimates per mailbox — Use these to estimate migration duration and bandwidth requirements

Document this inventory and share it with Legal and Compliance before migration begins. Missing retention rules, legal holds, or orphaned data stores can create audit and ediscovery problems later.

Step 3: Clean up and archive data before migration

Before you move data, reduce what actually needs to be migrated. Audit mailbox sizes, remove orphaned accounts, archive PST files, and identify stale or duplicate data that no longer needs to live in the production environment.

This is also the time to identify information subject to retention policies or legal holds. Migrating regulated data without a defensible chain of custody can create compliance exposure, which is why many organizations use third-party archiving to preserve data integrity before and during the move.

Step 4: Choose a deployment strategy

Microsoft offers a great deal of support, from deciding on the deployment strategy to in-depth coverage of performing each one. The choice depends on your company’s size, time frame goals, and whether you’re migrating from another email server or the Exchange Server.

Here are the most frequently used deployment methods for the migration, and each of them suits different timeframes and volumes of data. Microsoft also throttles large migrations, so organizations should plan for off-hours batch processing and stagger large mailbox moves.

• IMAP migration — Use the Exchange admin center or, alternatively, Exchange Online PowerShell to migrate content from an IMAP messaging system, including from other email services, such as Gmail or Yahoo Mail.
  Best for organizations migrating basic email content from IMAP-based systems that do not need calendar, contact, or task migration.
• Cutover migration — With cutover migration, you migrate all on-premises mailboxes to Microsoft 365 over a few days. Cutover migration supports up to 2,000 mailboxes, but Microsoft recommends keeping it to 150 or fewer. Performance degrades significantly with larger batches, and provisioning time increases.
  Best for small organizations that want a fast move from on-premises Exchange with minimal coexistence.
• Staged migration — A bit slower migration method, the staged migration lets you migrate batches of on-premises mailboxes to Microsoft 365 over a few weeks or months.
  Best for organizations that need to migrate in phases from Exchange Server 2003 or 2007.
• Hybrid deployment — A hybrid deployment can work as an intermediate step to a complete move to a Microsoft 365 organization. It enables a feature-rich experience and control with the existing on-premises Exchange organization, the same as the cloud.
  Best for mid-sized and large organizations that need long-term coexistence and typically run Exchange Server 2010 or later.
• Third-party migration — Use third-party migration tools if you need specific protocols and approaches for email migrations from specific platforms on particular terms.
  Best for complex environments, workload-heavy projects, or migrations that require platform-specific controls, reporting, or compliance safeguards.

Regardless of the choice of the deployment strategy, the most common deployment tasks that make it to the Microsoft 365 migration checklist are the following.

• Create new or synchronize accounts — add employees and assign licenses to Microsoft 365.
• Authenticate accounts — choose identity models of M365 accounts.
• Migrate all data — migrate various emails (Gmail, Outlook, etc.) and contacts to Microsoft 365.

In addition, to ensure the most effective migration, do not forget to:

• Store emails and files with a third-party archiver for easier use and accessibility.
• Use Microsoft tools for guidance on directory synchronization to Microsoft 365.

Workloads to Include in Your Migration Plan

Most Microsoft 365 migrations involve more than email. Make sure your checklist accounts for each workload you plan to move.

• Exchange email and mailboxes — Migrate messages, contacts, calendars, shared mailboxes, and permissions, then verify mail flow after cutover.
• OneDrive — Review personal file ownership, sharing links, and storage quotas before moving user files.
• SharePoint — Map document libraries, permissions, metadata, and retention settings so collaboration sites remain usable after migration.
• Teams — Plan for channels, memberships, files, and chat history, because these workloads often require different tools and limitations than mailbox migration.
• Shared calendars and collaboration data — Test delegated access and shared resources to make sure users can continue working without manual fixes.

Step 5: Roll out users, domains and licenses

Once accounts are created and authenticated, you’re ready to bring users into the new environment. This phase covers domain configuration, license assignment, and application setup. It’s also where most user-facing issues surface, so plan for a support buffer.

Create a communication plan that tells users what is changing, when it is changing, and what they need to do. Before full rollout, migrate a pilot group of 10 to 20 users so you can test workflows, permissions, and support processes in a controlled way.

It also helps to schedule short training sessions or distribute quick-start guides for Outlook, Teams, and OneDrive. During the first two weeks after cutover, set up a dedicated support channel such as a help desk ticket category or Microsoft Teams channel for migration-related issues.

Continue the rollout by these steps:

• Add a domain to Office 365
• Add users and assign appropriate licenses
• Configure Office 365 application settings

Step 6: Validate and test after migration

Once the rollout is complete, verify that the migration worked as expected before you decommission the source environment.

• Confirm mail flow to and from external domains.
• Verify calendar and contact sync for a sample of migrated users.
• Test shared mailbox permissions and delegated access.
• Validate DNS MX record propagation.
• Check Outlook profile connectivity and sign-in behavior.
• Run a sample ediscovery search to confirm data completeness.
• Collect user feedback within the first 48 hours and log recurring issues.

So, it’s evident that there is a lot involved in the Microsoft 365 migration checklist. Many factors determine the exact process – the size of your organization, current setup, goals, and particular preferences. The checklist provided in this article is a rough outline of things to consider when planning a migration deployment.

One thing is sure: preparing as much as possible and assessing the specific needs or troubleshoots will save you time and money.

Common Migration Risks and How to Avoid Them

Even well-planned migrations can fail if common risks are not addressed early. The following issues appear frequently in Microsoft 365 projects.

• Identity and permission mismatches — If users, groups, and delegated permissions are not mapped correctly, people can lose access to shared mailboxes, calendars, and files after cutover.
• Microsoft throttling during large batch moves — Large migrations can slow down unexpectedly, which is why it helps to stagger batches and schedule high-volume moves during off-hours.
• Data loss from unmapped or inactive mailboxes — Orphaned accounts, former employee mailboxes, and PST files are easy to miss if the inventory is incomplete.
• Calendar and contact sync failures with IMAP — IMAP is email-focused, so organizations that need full collaboration data should validate what will and will not migrate before choosing it.
• DNS propagation delays — MX record changes do not always take effect immediately, which can create temporary mail delivery gaps if the cutover window is too aggressive.
• Compliance gaps during transfer — When data under legal hold is moved without a defensible chain of custody, retention and auditability can break at exactly the wrong time.

How to Maintain Compliance During a Microsoft 365 Migration

Migration creates a period where data may exist in two systems at once, retention policies may not carry over automatically, and legal holds on source mailboxes may not transfer cleanly to the destination. For organizations in regulated sectors, that creates unnecessary risk during a time when visibility matters most.

If you are subject to frameworks such as HIPAA, SEC 17a-4, FINRA, or FOIA, build compliance controls into the migration plan before the first mailbox move begins. That means identifying retention requirements, validating legal hold coverage, preserving audit trails, and confirming that searchable records remain available throughout the transition.

A third-party archiving solution that operates independently of your email platform gives you a defensible, searchable copy of all communications before, during, and after the migration. Jatheon’s cloud archiving platform is fully compatible with Microsoft 365 and designed for organizations that need to meet HIPAA, SEC, FINRA, or FOIA requirements without relying on native Microsoft 365 archiving capabilities alone.

Summary of the Main Points

• A Microsoft 365 migration requires more than mailbox moves. You need a plan for identity, files, permissions, workloads, and compliance controls.
• Start by defining measurable goals and creating a complete inventory that includes retention policies, legal holds, PST files, and mailbox data volumes.
• Clean up stale data before migration, then choose the deployment method that matches your source environment, timeline, and coexistence requirements.
• Roll out users with a pilot group, clear communication, training, and a dedicated support process for the first two weeks after cutover.
• Validate mail flow, permissions, DNS, and data completeness after migration, and do not decommission the source until those checks are complete.
• For regulated organizations, preserving retention, legal hold, and auditability throughout the move is just as important as completing the migration itself.

FAQ

How do you create a Microsoft Office 365 migration checklist?

Start by documenting your migration goals, stakeholders, source systems, users, mailboxes, storage locations, applications, retention policies, legal holds, and data volumes. Then organize the work into phases: communication, inventory, cleanup, deployment method selection, rollout, and post-migration validation. A good checklist also includes compliance sign-off before decommissioning the source environment.

What is the best migration method for small organizations with fewer than 150 mailboxes?

For many small organizations moving from on-premises Exchange, cutover migration is the most practical option because it moves all mailboxes in a single project window. Microsoft supports up to 2,000 mailboxes for cutover, but recommends 150 or fewer for performance reasons. If you only need to move email from another IMAP-based system, IMAP migration may be enough, but it does not include calendars, contacts, or tasks.

How do you maintain compliance during a Microsoft 365 migration?

Identify retention rules, legal holds, and audit requirements before migration begins, then verify that those controls will remain active in the destination environment. Because data may exist in two systems at once during migration, many regulated organizations use independent archiving to preserve a searchable, tamper-resistant record throughout the process. This is especially important for organizations subject to HIPAA, FINRA, SEC 17a-4, FOIA, or similar frameworks.

What should you do after a Microsoft Office 365 migration is complete?

Run post-migration validation checks before shutting down the source environment. Confirm mail flow, test Outlook connectivity, review shared mailbox permissions, verify DNS propagation, check calendar and contact sync, and run a sample ediscovery search to confirm data completeness. It also helps to collect user feedback within the first 48 hours so recurring issues can be fixed quickly.

How long does a Microsoft 365 migration take?

The timeline depends on the migration method, data volume, bandwidth, and the condition of the source environment. A small cutover migration may finish in a few days, while staged or hybrid migrations can take several weeks or months because they involve coexistence, batch planning, and more user coordination. Cleanup, testing, and validation often take longer than the final cutover itself.

About the Author

Stefan Jovanovic

Stefan Jovanovic is a PR and SEO Manager at Jatheon who specializes in B2B SaaS marketing and outreach strategies that drive engagement, generate leads, and support business growth. Outside of work, he enjoys photography, social media, and writing.