Most Microsoft 365 migrations that fail don't fail during the migration. They fail in the weeks before it, because nobody audited the source environment, nobody designed the target tenant, nobody told users what was changing, or nobody had a tested rollback plan.
This checklist covers the 15 things you need in place before you start moving a single mailbox or file. It's written for organizations migrating from on-premises Exchange, Google Workspace, or a legacy Microsoft 365 tenant, but the fundamentals apply everywhere.
Phase 1: Discovery and Assessment
1. Complete a source environment inventory
Before you can design the target, you need to know what you're moving. Inventory includes: all user accounts (active, inactive, shared), all mailboxes and their sizes, all distribution groups, all shared mailboxes, public folders, all SharePoint or file server content with size and age, and any third-party integrations that touch email or files (CRMs, accounting systems, HR platforms).
Tools: Microsoft's MFCMAPI for Exchange, SharePoint Migration Assessment Tool (SMAT) for SharePoint, Azure AD Connect Health for hybrid environments.
2. Identify your data and regulatory requirements
Do you have a records retention policy? Are any communications subject to legal hold or eDiscovery requirements? Are there industry-specific regulations (HIPAA, PIPEDA, GDPR, FedRAMP) that dictate where data can reside or how long it must be kept?
These requirements drive Microsoft 365 plan selection, data residency decisions, and the Microsoft Purview configuration that needs to be in place on day one.
3. Clean your source data before migrating
A migration is an opportunity to clean up years of accumulated data debt, not an obligation to preserve every email from 2009. Remove accounts for employees who left more than 2 years ago. Archive or delete content that hasn't been accessed in 3+ years. Consolidate redundant distribution groups.
Every gigabyte of unnecessary data you don't migrate is time, cost, and complexity you avoid.
Phase 2: Tenant Design and Security
4. Design your Entra ID (Azure AD) structure
Your Microsoft 365 tenant is built on Entra ID. Before any migration work starts, design your identity structure: naming conventions for users, groups, and service accounts; group types (security groups vs Microsoft 365 groups); synchronization model (cloud-only, synchronized from on-premises Active Directory, or hybrid); and Privileged Identity Management (PIM) for admin accounts.
Identity architecture decisions made early are expensive to undo later. Get them right at the design stage.
5. Configure Multi-Factor Authentication before migration starts
MFA should be mandatory for all accounts before any production data enters Microsoft 365. This is non-negotiable from a security standpoint and increasingly required by cyber insurance policies.
Use Conditional Access policies (not the legacy per-user MFA settings) for flexibility. At minimum, require MFA for all administrative actions and for access to sensitive applications. Microsoft Authenticator app is the recommended second factor.
6. Plan your Conditional Access policies
Conditional Access is the policy engine that controls who can access Microsoft 365, from what devices, from what locations, under what risk conditions. Design these policies before migration, not after.
Key policies to define upfront: MFA for all users, block legacy authentication protocols (SMTP Auth, Basic Auth), require compliant device for access to sensitive apps, block access from high-risk sign-in locations unless MFA is satisfied.
7. Configure Microsoft Defender for Microsoft 365
Exchange Online Protection (EOP) is included with every Microsoft 365 plan and provides baseline email security. Defender for Office 365 Plan 1 (included in M365 Business Premium and above) adds Safe Links, Safe Attachments, and anti-phishing policies.
Configure these before your first mailbox is live in Exchange Online. A misconfigured or unconfigured email security policy on a live mailbox is an open door.
Phase 3: DNS and Mail Flow
8. Understand your DNS TTL and plan changes accordingly
Changing your MX record (which directs mail to Exchange Online) is the point of no return for email migration. DNS propagation takes 24-48 hours at standard TTLs.
Two weeks before your planned cutover, lower your TTL for MX, Autodiscover, and SPF records to 300 seconds (5 minutes). This means changes propagate in minutes on cutover day. Restore TTLs to standard values after the migration is stable.
9. Add and verify your domains in Microsoft 365
Every domain you plan to use in Microsoft 365 (for email, SharePoint URLs, Teams) must be added and verified before migration. Domain verification requires adding a TXT record to your DNS zone.
Do this well in advance. DNS change approval, zone access issues, and domain registrar delays have derailed more than a few migration timelines.
10. Configure and test SPF, DKIM, and DMARC
SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication) are email authentication standards that protect your domain from spoofing and improve deliverability.
All three must be configured correctly before cutover. Test them using tools like MXToolbox or mail-tester.com. A missing or incorrect DMARC record can result in legitimate email being rejected by recipients after migration.
Phase 4: Data Migration Planning
11. Choose and test your migration method
Three primary migration methods for email:
- Cutover migration: Move all mailboxes at once. Suitable for organizations under 150 mailboxes migrating from Exchange 2010 or earlier.
- Staged migration: Move mailboxes in batches. Suitable for larger Exchange on-premises environments.
- IMAP migration: For non-Exchange sources (Google Workspace, other IMAP servers). Moves email only. No calendar or contacts.
- Hybrid migration: Coexistence between on-premises Exchange and Exchange Online. Most flexible, most complex. Requires Azure AD Connect.
Test your chosen method with a pilot group of 10-15 users before the full migration. Identify and resolve issues in the pilot before they affect hundreds of users.
12. Plan SharePoint and OneDrive migration separately
File migration is often more complex than email migration because of folder depth limits, file name restrictions, and SharePoint's permissions model. Microsoft's SharePoint Migration Tool (SPMT) handles migrations from on-premises SharePoint and file servers. Third-party tools like Sharegate and Metalogix handle more complex scenarios.
Use the migration assessment phase to identify files that will fail due to path length, illegal characters, or size. Clean these up in the source before migration begins.
Phase 5: User Readiness
13. Communicate the timeline clearly and early
Users who are surprised by a migration are users who fight it. Start communicating 4-6 weeks before cutover. Tell them: what's changing, when it's changing, what they need to do (if anything), where to get help, and what the rollback plan is if something goes wrong.
Use multiple channels: email, Teams, intranet, manager briefings. Repetition matters. Most people don't act on the first notification.
14. Run training before go-live, not after
Training users on Outlook, Teams, and OneDrive after they've already been migrated, while they're trying to do their actual jobs in an unfamiliar interface, is the least effective way to drive adoption.
Run role-based training sessions 2-3 weeks before go-live. Focus on the workflows that matter most to each group. Record sessions for staff who can't attend live.
15. Define and staff your go-live support model
On cutover day and for at least a week after, you need more helpdesk capacity than normal. Define clearly: who users should call when they have a problem, what the escalation path is for critical issues, how long the on-premises environment will remain accessible as a fallback, and what constitutes a trigger for rolling back.
The rollback question is uncomfortable but essential. Agreeing in advance on what would cause a rollback (and having a tested plan for executing it) is the difference between a controlled incident and a crisis.
Frequently Asked Questions
How long does a Microsoft 365 migration take?
A standard Microsoft 365 migration for an organization of 100-300 users typically takes 10-16 weeks from kickoff to go-live, including discovery, design, testing, and the migration itself. Larger or more complex environments (hybrid Exchange, large SharePoint environments, extensive integrations) take longer.
What is the most common Microsoft 365 migration mistake?
Starting the technical migration before the source environment is fully inventoried and cleaned. Migrating unknown or uncleaned data creates support burdens and governance debt that organizations deal with for years after go-live.
Can we stay on-premises and connect to Microsoft 365?
Yes. Microsoft supports hybrid configurations where some users remain on-premises Exchange or SharePoint while others are in the cloud. However, hybrid environments are significantly more complex to manage than cloud-only, and Microsoft has been progressively reducing investment in on-premises versions. Hybrid is usually a transitional state, not a permanent destination.
Should we migrate email first or SharePoint files first?
In most cases, email first. Email has a clear cutover point (MX record change) and a well-understood user impact. SharePoint migrations can be phased over weeks or months with less disruption. Completing email migration first also gives your team confidence and experience with the migration process before tackling the typically more complex file migration.