We migrated a company with roughly 50 Microsoft 365 users into our tenant. About 20 existing computers had to be wiped and re-enrolled, while another 16 new devices were purchased and enrolled through Autopilot. Three of us, a family member helping out, and two MSP technicians spent nearly two full days getting everything done.
That experience made me wonder how organizations handle migrations involving hundreds or thousands of users. Since a custom domain has to be removed from the source tenant before it can be added to the destination tenant, I'm not sure how people stage the transition. Do users temporarily receive a new address in the destination tenant while mail is forwarded from the old domain? How are devices, email, SharePoint, Teams, identity, and business applications handled during the transition?
For our migration, we prepared as much as possible, removed the domain, changed DNS, added the domain to the new tenant, and waited for everything to become available. What does a typical large-scale migration process look like?
5 Answers
Everything needs its own migration plan. Email and OneDrive are one workstream; Active Directory or identity synchronization is another; SharePoint and Teams have their own permissions and content concerns; and SSO applications, Dynamics, phone systems, workflows, and line-of-business apps may require manual reconfiguration. The successful projects start with a detailed inventory, test migrations, clear user communications, and a written cutover playbook.
The domain cutover is only one part of the job. Email and user data can be synchronized ahead of time with tools such as Quest, BitTitan, ShareGate, or similar products. Devices may be wiped and re-enrolled, replaced, or temporarily accessed through Azure Virtual Desktop or another VDI solution. Remote users are often the most difficult because they need to be online and connected to the right VPN while identities, profiles, permissions, and device access are changed.
Large migrations are usually handled as a project over weeks or months, not as one huge cutover. The team inventories every workload first, creates identities and destination resources, migrates data in stages, and runs a final delta sync during the cutover window. The exact timeline depends on how much data, how many applications, and how much staff are available.
A common approach is to build and validate the destination environment while the old tenant remains active. Content, Teams, sites, automations, and application integrations are prepared in advance, and users or site owners test the results. During the cutover weekend, the domain is released and added to the new tenant, DNS is updated, a final synchronization is performed, and users are moved over. Complex applications can require several more months of cleanup and validation afterward.
For very large environments, organizations often issue destination identities first and gradually move services over rather than trying to move every user and device at once. Third-party migration tools are common, although Microsoft’s built-in options may work for some scenarios and have their own identity and workload limitations. The key is treating this as coordinated change management and application migration, not just a domain swap.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures