An important part of Microsoft 365 (formerly Office 365) migration is choosing the right migration method. This article breaks down the different types of Microsoft 365 migrations and offers key strategies and technical approaches for the primary Microsoft 365 workloads.
Microsoft 365 migration scenarios
Microsoft 365 migrations can take different forms depending on the business context, technical requirements and source environment. Organizations may need to migrate to Microsoft 365 from an existing tenant, an on-premises or hybrid infrastructure, or a third-party platform.
Tenant-to-tenant migration
Tenant-to-tenant migrations occur when an organization moves its Microsoft 365 workloads from one tenant to another. This is common in mergers, acquisitions, divestitures and rebrands.
If the source or target tenant has multi-geo capabilities or is a tenant in Microsoft’s Government Community Cloud (GCC) or Government Community Cloud High (GCC High) or Department of Defense (DoD) environments, additional considerations are required.
Migration from an on-premises environment to Microsoft 365
On-premises to cloud migration refers to moving workloads from on-premises infrastructure to Microsoft 365. This is common for organizations shifting from on-premises Exchange, SharePoint, file servers or traditional identity management systems to Microsoft’s cloud-based services. The migration process varies based on the workload, data volume and complexity of integrations with legacy systems.
Hybrid migration
Some organizations are not ready or able to fully move to Microsoft 365 due to on-premises dependencies, compliance requirements or application integrations that require an on-prem environment. A hybrid migration enables them to leverage cloud benefits without fully decommissioning their on-prem infrastructure, ensuring business continuity. The organization might then gradually transition to a full cloud environment, or maintain a hybrid setup indefinitely due to technical, regulatory or operational constraints.
Hybrid setups are common in large enterprises, government agencies, industries with strict data residency requirements and other regulatory constraints, and organizations with significant legacy dependencies.
Migration from a third-party platform to Microsoft 365
The final Microsoft 365 migration type involves moving workloads from non-Microsoft platforms into Microsoft 365. These migrations are common during digital transformation initiatives, mergers and acquisitions, cost optimization efforts, and security and compliance improvements.
Depending on the platform, different approaches are required. Not all objects can be migrated like-for-like because different platforms have unique architectures, permission models and feature sets that may not map directly to Microsoft 365. Some elements may not be able to be migrated at all, so workarounds, replacements or alternative solutions may be required to maintain functionality. Organizations should expect some restructuring of permissions, workflows and metadata to align with Microsoft 365’s authentication, security and access models.
Microsoft 365 migration strategies
Regardless of source environment, choosing the right migration strategy depends on factors such as organization size, data volume, environment complexity and business continuity requirements. The two most common approaches are phased migration and cutover migration.
Phased migration
A phased migration involves migrating data in stages or waves rather than all at once. This approach is commonly used in large organizations, complex environments and businesses that need to minimize operational disruption.
Users and data are migrated in batches, often based on department, location or priority. This approach allows IT teams to test and validate each group before moving the next one, which reduces risk by ensuring that any issues are addressed promptly.
During a phased migration, users can coexist in both the source and target environments so they maintain access to critical systems throughout the transition. However, careful planning is required to ensure that dependencies, such as email routing and file access, function correctly across environments.
Cutover migration
In a cutover migration, also referred to as a big-bang migration, all users and data are moved from the source environment to Microsoft 365 in a single event. The migration is often scheduled over a weekend or during off-peak hours to minimize disruption. All users begin using the new system immediately afterward.
While a cutover migration is simpler to plan and execute than a phased migration, it carries a higher risk of disruption and post-migration issues. It is best suited for smaller organizations that have minimal dependencies and that can tolerate downtime for a short period.
Because users must fully adopt Microsoft 365 as soon as the migration is completed, strong pre-migration planning is essential, including clear communication, training and contingency plans to address any challenges that may occur.
Technical aspects of Microsoft 365 migration
Microsoft 365 migrations involve multiple technical considerations depending on the type of data being migrated, the source environment and organizational needs. The following sections dive into the most common Microsoft 365 migration workloads.
Domain migration
Domain migration is almost always part of Microsoft 365 migration. The exception is when the company plans to use a new domain after migration and does not want to use the old domain for email aliases.
Please note that domains cannot be shared between tenants. In a phased migration, this limitation can be handled by staging users in the target with a temporary domain (for instance, the onmicrosoft.com internal domain).
Domain migration can take longer than expected due to factors like DNS propagation delays, sync issues, mail flow conflicts and external systems that use the domain. It is recommended to open a proactive remediation ticket with Microsoft prior to beginning domain migration to ensure that support is available if needed.
Identity and device migration
Entra ID (formerly Azure Active Directory) is a key component of any Microsoft 365 migration. Identity migration involves transferring user accounts, security groups and distribution lists from the source to the target. Device migration ensures that corporate-managed devices retain their identities and policies in the new tenant, supporting authentication, conditional access and compliance enforcement policies.
Device migration
Device migration is also almost always part of Microsoft 365 migration. The exception is devices that are unmanaged — which is not recommended due to security and compliance risks.
The approach for device migration can vary depending on whether devices are enrolled in Intune (Microsoft 365), controlled via Group Policy (on-premises), or managed by a third-party device management product. Whether an organization uses cloud-only identity, hybrid identity or federated identity also affects the migration approach, including authentication changes and which device policies can be retained.
Cloud-to-cloud identity migration
Identities can be migrated from one Microsoft 365 tenant to another, or from a non-Microsoft cloud platform a few different ways: manually, via bulk import, using PowerShell, or via third-party migration tools.
On-prem-to-cloud or hybrid-to-cloud identity migration
There are various sync scenarios for on-premises Active Directory and Entra ID in Microsoft 365. Microsoft has a setup guide to help you determine whether users should be created or synced and which sync tool to use. They also provide a table that outlines common sync scenarios and which tools support them.
Synchronization is typically recommended, but if it is not feasible, objects can be created manually, via bulk import or with third-party migration tools.
Mailbox migration
Mailbox migration primarily involves transferring email data. However, depending on the migration method and source system, it may also include calendars, contacts and tasks. The preferred migration approach depends on factors such as the source email system, the number of mailboxes and specific organizational requirements.
Tenant-to-tenant mailbox migration
Third-party tooling is typically used for tenant-to-tenant mailbox migration, as outlined in this article from Microsoft. Microsoft did recently release a cross-tenant mailbox migration tool to Public Preview; however, in my experience, preview features are not recommended for migrating production data due to the associated risk.
On-premises Exchange to Exchange Online migration
Migration from on-premises Exchange to Exchange Online can be performed using Exchange hybrid migration, staged migration or cutover migration, depending on the environment. If you are using an older version of Exchange (like 2007), you may be required to use third-party tools to onboard.
This documentation from Microsoft outlines the recommended migration path to take based on your Exchange Server system and the number of mailboxes to be migrated. Users with a large amount of data to be migrated (over 100 GB) require additional migration steps.
Internet Mail Access Protocol (IMAP) migration
IMAP mailbox migration transfers only email data from source mailboxes to Microsoft 365. It is typically used with older email services that do not support more robust migration methods, such as older third-party email providers and Exchange Server versions older than 2003. Note that Large Archive Onboarding (LAO) is required to migrate IMAP mailboxes over 100 GB.
In some scenarios in which only email data (and not calendar items, tasks or contacts) needs to be migrated, IMAP migration can reduce migration project costs.
OneDrive and SharePoint file migration
File migrations to OneDrive and SharePoint are typically organized into personal files and shared data: The files of individual users are migrated to OneDrive, while shared files are moved to SharePoint (since sharing is the point of SharePoint 😉). Migration methods vary depending on the source environment.
Individual user files
User files stored in on-premises home drives, desktops or non-Microsoft cloud storage platforms are typically migrated to OneDrive for Business.
Microsoft provides tools like Known Folder Move to redirect users’ Desktop, Documents, Pictures, Screenshots and Camera Roll folders to OneDrive, keeping files synced automatically.
Otherwise, when migrating from home drives or non-Microsoft cloud platforms, user files are mapped to the correct accounts in OneDrive and then migrated, using either Microsoft’s Migration Manager or third-party migration tools.
Similarly, in Microsoft 365 tenant-to-tenant migration, OneDrive accounts are mapped between the source and target tenant and migrated using Microsoft cross-tenant migration or third-party migration tools.
Shared files
Shared files in on-premises file shares or intranet sites or non-Microsoft cloud storage platforms are typically migrated to SharePoint Online. A key consideration is determining whether content should be moved into standalone SharePoint sites or sites associated with Microsoft Teams (which uses SharePoint for file storage): SharePoint sites work best for structured document storage, while Teams integrates chat-based collaboration with SharePoint’s file storage system, organizing files in Teams channels.
Shared content from file shares or non-Microsoft platforms can be migrated using Microsoft’s Migration Manager (for supported sources) or third-party migration tools. Please note that content migrated from these sources often uses permission models that don’t directly map to how permissions are managed in Microsoft 365, and permission mapping may require redesigning how permissions are granted.
For tenant-to-tenant migrations, SharePoint document libraries and Teams files are mapped between the source and target tenant, ensuring that site structure, data, metadata, permissions and sharing links are retained where possible. Currently, Microsoft’s cross-tenant SharePoint migration tooling is in Private Preview; third-party tools are recommended for SharePoint Online tenant-to-tenant migration.
For organizations migrating from on-premises SharePoint Server to SharePoint Online, the approach depends on the version of SharePoint and the complexity of the environment. Microsoft provides the SharePoint Migration Tool (SPMT) to migrate to SharePoint and Teams from SharePoint Server 2010 and later. During migration, considerations include site structure, metadata, workflows and custom solutions that may need to be reconfigured to align with modern SharePoint Online capabilities. Classic sites can be upgraded to modern experiences, which provide improved usability, mobile responsiveness and integration with Microsoft 365 services. Organizations should also evaluate any custom web parts, InfoPath forms and on-premises workflows in the source SharePoint Server environment; migrating them may require redevelopment or replacement in Microsoft 365. SPMT can be used to migrate supported SharePoint Server workflows to Power Automate.
Teams migration
Microsoft Teams migration involves transferring chat history, channels, team memberships, files and settings. The migration approach depends on whether Teams data is being moved between Microsoft 365 tenants or from third-party collaboration platforms.
One solution. Many workloads.
For tenant-to-tenant Teams migration, data is mapped between the source and target tenant. Since Teams migration involves multiple interconnected services such as SharePoint, OneDrive and Exchange, organizations should account for dependencies to ensure a seamless transition. Private channels, Planner tasks and chat history may require additional migration steps to maintain full functionality. Third-party migration tools are recommended for this process.
For organizations migrating from third-party collaboration platforms, the process typically involves exporting messages, files and user data from the source platform and importing them into Teams. Since direct migrations are not natively supported, organizations may need to use scripts or third-party migration tools to facilitate migration, and they should expect that some data and metadata cannot be migrated.
Key takeaways: Microsoft 365 migration types and strategies
Selecting the right approach depends on your source environment, business objectives and technical requirements. As you plan your migration, be sure to keep the following in mind:
- Domain migration is a critical step when an organization needs to retain its existing domain. Proper planning is essential to avoid downtime.
- Phased migrations enable organizations to move data in stages for a smoother transition. Cutover migrations move everything at once, so they are best suited for smaller environments.
- Different workloads require different migration tools and approaches. Microsoft provides built-in migration tools for some scenarios, but third-party solutions are often necessary for complex migrations.
- Not all objects can be migrated like-for-like. Some platforms have unique architectures that require workarounds or alternative solutions to maintain functionality in Microsoft 365.
By considering these key points, organizations can choose the best Microsoft 365 migration approach for their needs.
