If you have about 150 mailboxes or fewer, a cutover migration is usually the fastest route. Larger or multi-workload moves fit a staged, hybrid or Migration Orchestrator approach. Your first action is the same either way: run a complete inventory and create a validation batch. Lower your DNS TTL, confirm licences exist in the target tenant, and schedule the pilot two weeks before cutover.
TL;DR:
- Inventory mailbox sizes, shared mailboxes, cloud files, Teams data, and legal holds, then assign content owners so batch sizes and later checks have reliable baselines.
- Keep at least 20% network capacity beyond peak demand, and avoid restrictive proxy authentication or packet inspection that can trigger Microsoft 365 throttling.
- A batch must reach ValidatePassed before migration, and administrators must revalidate it if more than seven days pass; failed users can be retried separately.
- Microsoft throttles background migration during peak weekday hours, so schedule work at night or on weekends and set concurrency within each endpoint’s limits.
- After the move, compare mail counts, permissions, and cloud content against discovery totals, then recreate transport rules and plan legacy system decommissioning.
Treat this as the day-to-day list. Each item has a section below with the detail behind it.
Pro Tip: Put a named owner and a date next to every line of this list before the project starts. Unowned tasks are the ones that slip into cutover week.
Discovery decides everything that follows. A rough headcount is not enough. You need measurements, because your approach, batch sizes and risk list all come from them.
Capture these items:
Next, record anything that can block a move: legal holds, retention policies and mailboxes on hold. If you have not set up retention yet, our Exchange Online retention policies guide walks through it for admins. Holds found during discovery are an annoyance. Holds found on cutover day are an outage.
Then map account ownership and content owners. When a department head approves the scope of their own team’s move, you avoid disputes later and can plan scoped moves with sign-off.
Finally, use the totals to estimate overall data volume, size your batches and pick a pilot group. A site with a few huge mailboxes behaves very differently from one with many small ones, even when the headcount matches. Document the numbers now, because you will compare them against the destination after the move.
Pick by size, workload scope and how much disruption the business can absorb. Microsoft recommends cutover migrations for up to about 150 mailboxes. It technically supports up to 2,000, but performance usually degrades, so hybrid and staged approaches suit larger organisations. Its path selection guidance turns on your source system and mailbox count.
Pro Tip: If your answer sits between two options, choose the one that lets you migrate in smaller groups. Being able to pause after a pilot is worth more than raw speed.
Most failed validations trace back to preparation. Work through this list in order.
Scheduling matters too. Microsoft throttles background migration operations during peak weekday hours, and the rules cannot be suspended. Nights and weekends generally give better throughput.
Pro Tip: Test the full path, not just bandwidth. Send a test message and sign in from a managed device in the target tenant before your pilot users do.
A pilot exists to expose problems while they are cheap. Include representative users, a few VIPs and known edge cases such as heavy shared mailbox users or people with large archives. A representative group of users gives a realistic soak without creating a support crush.
Validation is your first gate. Creating a batch triggers an automatic what-if check of licensing, identity mapping and permissions for every user. If one user fails, that user fails while the others proceed. A batch must reach ValidatePassed before you migrate, and validation is only good for seven days.
Set pass criteria in writing before you start:
When something fails, fix the cause, revalidate, and retry failed users in a new batch once prerequisites are met.
Pro Tip: Ask pilot users to report in one shared channel. A single log of issues makes patterns visible that individual tickets hide.
The lifecycle is: create, validate, migrate, cutover. Here is the sequence in operational order.
For SharePoint and OneDrive, content packaging matters as much as scheduling. Microsoft recommends at least 250 files and a package size of at least 100 MB but less than 250 MB. Run tasks in parallel across site collections, but avoid queuing more jobs than recommended or you invite throttling.
Migration is not finished when the last mailbox moves. It finishes when you can prove nothing was lost and nothing risky remains in the old environment.
Our Microsoft 365 optimization page covers the configuration work that usually follows cutover.
Technical success can still end in a poor outcome if users are lost on day one. Start with a cross-functional team of stakeholders, champions and IT representatives. Microsoft’s change guide advises including people from multiple departments in planning and testing, so the setup fits real workflows and not just IT settings.
Midsize migration timelines vary, because the gates matter more than the data copy. A sample phased schedule:
Total data volume, mailbox counts, network capacity and the chosen method all move this timeline. Two rules of thumb hold up: run the pilot two weeks before cutover, and treat compressing a 500-user migration below 10 weeks as a risk, not a saving.
We do not treat a migration as a data copy. The step that prevents the most pain is the least glamorous one: refusing to schedule cutover until the pilot has passed its written criteria. Teams under deadline pressure skip that gate, and users pay for it in the first week.
NetFusion Designs is a certified managed IT provider with teams across Ontario and Canada. We run pilot and batch projects, co-managed or fully managed, backed by a Network Operations Center.
— Geeshan
If you would rather hand this checklist to a team that works through it every week, we manage Microsoft 365 migrations from inventory to decommissioning, under a SOC 2 Type II certified process. Ask for an assessment, book a migration readiness review or schedule a pilot migration with us. Start with our Managed IT Services page and tell us your mailbox count.
Inventory the mailbox, confirm its licence in the target tenant, create a migration batch and let validation pass. Then call migrate, monitor for errors and complete the cutover by updating MX/DNS and checking Outlook connectivity. Validation passes are valid for seven days, so migrate within that window.
Plan scope and workloads, prepare the target tenant (licences, verified domains, admin accounts), and run a pilot batch first. Then migrate in validated batches and finish with DNS cutover and cleanup. For coordinated moves across mail, OneDrive, SharePoint and Teams, Migration Orchestrator sequences the workloads.
The subscription is tied to your account, not a device, so you sign in on the new computer and reinstall the apps. Your mailbox and cloud files stay in your tenant. That is different from a tenant migration, which moves data between organisations.
It depends on scope. Cutover tools fit small mailbox moves, hybrid suits larger Exchange moves, and Migration Orchestrator suits multi-workload tenant moves. Consider a third-party tool or partner when you need advanced mapping or metadata fidelity, as Microsoft’s tenant-to-tenant planning guidance describes.
%20(1).avif){kind=logo}
%201.avif)
