We recently migrated a company with roughly 50 users into our Microsoft 365 tenant. About 20 computers had to be wiped and re-enrolled, while another 16 new devices were purchased and enrolled through Autopilot. Three of us, plus a few extra helpers, spent two exhausting days getting everything across the finish line.
That made me wonder how migrations work when hundreds or thousands of users are involved. Since a custom domain has to be removed from the old tenant before it can be added to the new one, how do people stage the migration? Do users temporarily get a different sign-in address while mail and other services are gradually moved, with the original domain forwarded until cutover?
For our project, we prepared as much as possible, removed the domain, changed DNS, added the domain to the destination tenant, and waited for everything to update. I'm interested in the planning, tools, and cutover methods used for much larger migrations.
5 Answers
At larger scales, you generally create new identities in the destination tenant and migrate users, mail, files, devices, and applications in stages. The schedule depends on how much data and how many services are involved. The domain cutover is only one part of the project; identity mapping and service dependencies usually take much more planning.
A migration of several thousand users is treated more like a program than a weekend deployment. Large projects may involve months of planning, pilot groups, communication, vendor coordination, and a detailed runbook. One major migration had content and Teams prepared months in advance, mail synchronized before the cutover, and owners validating sites. The cutover itself was clean, but application cleanup and validation continued for months afterward.
There is no single migration button for every workload. Email may use a dedicated migration service, directory synchronization may require a separate tool, SharePoint often needs its own migration process, and enterprise applications or SSO integrations may have to be manually reconfigured. The safest plan is to break the project into separate workstreams, test each one with a pilot group, and clearly document the order of operations.
The usual approach is coexistence and extensive preparation. Inventory every workload first: email, identities, Active Directory, SharePoint, Teams, telephony, line-of-business applications, SSO, and automations. Data can be pre-staged and synchronized ahead of time, with a final delta sync during the cutover window. The domain is then moved after the old tenant no longer depends on it, followed by DNS changes, testing, and user validation.
Migration tools such as Quest, BitTitan, ShareGate, and other specialist products are commonly used for mail, OneDrive, SharePoint, and related data. Devices and remote users are often the difficult part because they may need to be re-ACL'd, re-enrolled, or connected through VPN during the transition. Some organizations provide temporary virtual desktops in the destination tenant while physical devices are being rebuilt.
That kind of preparation is especially important when business applications depend on SharePoint or other Microsoft 365 services. Those integrations often determine the schedule more than the mailbox migration does.