Ask any IT team that has been through a rough Microsoft 365 migration where it went wrong. Most will point to something that was known during planning but not resolved before go-live. A missing inventory, an identity configuration left for later, or a network assessment that never happened. The cutover just made it visible.
This rundown covers the five areas where those gaps frequently show up before any Microsoft 365 migration services engagement or in-house cutover begins. Those areas are environment discovery, identity readiness, compliance configuration, network assessment, and pilot testing.
What the Pre-Migration Phase Needs to Cover
1. Take Stock of What You Actually Have
Most environments are messier than their documentation suggests. Shared mailboxes that belong to no one, distribution lists nobody has audited in 3 years, and on-premises integrations set up by someone who left 4 years ago. These show up as migration blockers if they surface during the cutover window rather than before it.
Pull a complete mailbox inventory, including shared, room, and resource accounts. Note the on-premises Exchange version and document any hybrid configuration already in place. List every application authenticating against on-premises Active Directory. Some of those will need cloud equivalents before the migration can complete without breaking something downstream.
Licensing decisions belong here too. Which users need Teams Phone? Who requires compliance workloads? Getting this mapped before provisioning saves corrective work that is genuinely annoying to do mid-project.
2. Identity Configuration Comes Before Data Movement
Azure AD Connect sync, MFA enforcement, and Conditional Access all need to be configured and validated before mailboxes start moving.
Microsoft 365 authentication runs through Microsoft Entra ID, and identity gaps have a way of surfacing at the worst possible time.
Three things that get missed more often than they should:
- Service accounts: on-prem service accounts need cloud equivalents set up ahead of the cutover, not during it
- Non-Intune devices: if Conditional Access goes live and devices are not enrolled, resource access breaks without much warning
- Guest access: how external sharing works in the new environment needs to be decided before migration, not after
Office 365 migration services teams catch these in discovery. In-house teams need to build this check into the pre-migration phase explicitly.
3. Compliance Configuration Has Its Own Timeline
Sensitivity labels, retention policies, and eDiscovery settings should not be figured out after data has moved. For organizations in healthcare, finance, or legal sectors, compliance configuration runs as a separate workstream alongside the technical preparation.
Check whether any mailboxes are under litigation hold in the source environment before anything moves. Those require specific handling. Also, confirm the target Microsoft 365 data center region meets data residency requirements for your industry. Changing this after provisioning is not straightforward.
4. The Network Assessment Most Teams Delay
Teams Voice, SharePoint sync, and Exchange Online each carry different bandwidth and latency demands. Most corporate networks were not built with these workloads in mind, and that mismatch does not always appear during testing. It appears in week one of production use.
Run workload-specific bandwidth assessments. Check whether Microsoft 365 traffic is passing through proxies or firewalls that will throttle it. Validate DNS configuration, split DNS in particular. Microsoft publishes a full list of required URLs and IP address ranges; run your endpoints against it before go-live. Organizations using managed IT services across multiple sites typically feel network gaps more acutely because the problem compounds at each location.
5. A Pilot Migration Is Where the Planning Gets Tested
Documentation preparation tells you what should happen. The pilot tells you what actually happens. Select a group that spans different departments, device types, and connectivity conditions. Run it, check mail flow, calendar sync, Teams, and SharePoint access, and write down what broke.
Set success criteria before the pilot runs. What ticket volume in the first week is acceptable? What does reasonable mail flow latency look like for your organization? Teams with defined benchmarks make the go or no-go decision based on numbers. Teams without them make it based on instinct, which becomes a harder conversation when something is visibly wrong.
Write the rollback plan before cutover day. Document the trigger criteria and get them agreed upon. It changes how people behave when things get tense during the window.
Conclusion
Pre-migration is where Microsoft 365 projects are won or lost. The cutover just reveals which category you land in. Environment discovery, identity readiness, compliance alignment, network assessment, and a structured pilot are what determine how day one goes. The difficulty is not technical complexity. It is doing the work thoroughly rather than treating it as overhead before the migration starts.
Author: Jinal Khimani
Marketing Manager
Jinal Khimani leads marketing at Infrassist with a love for structure, strategy, and sweating the details. A software engineer turned marketer, she’s all about clear messaging and adding just the right personality to brands. Whether it’s refining positioning, curating funnels, or shaping go-to-market plans, she’s always out there asking the right questions to ensure every piece fits into the overall strategy (usually with a coffee in hand).
Social Media
LinkedIn:
https://www.linkedin.com/company/infrassist-technologies
Facebook:
https://www.facebook.com/Infrassisttechnologies
Twitter:
https://x.com/InfrassistTech