Your SharePoint sites may need to move to a new Microsoft 365 tenant because of a merger, acquisition, tenant consolidation, or company restructuring, but the real challenge starts when you realize that moving the files alone is not enough. Users still need the right permissions, shared links need to work, workflows may depend on the old tenant, and business teams cannot afford to lose access during the cutover. From the SharePoint migrations we handle at Code Creators, we have found that most issues appear around user identities, permissions, Microsoft 365 groups, and connected processes rather than the file transfer itself. These dependencies need to be addressed before the move because problems in any of them can affect access and functionality after migration.
In this article, you will learn how to complete a SharePoint tenant to tenant migration, which tools you can use, and what you need to check before, during, and after the move.
How to Migrate SharePoint from One Tenant to Another?
To migrate SharePoint from one tenant to another, first inventory the source environment and map users, groups, permissions, and sites to the target tenant. Then prepare both tenants, choose a supported migration method, test representative sites, complete the production move, and validate access, links, workflows, and integrations afterward.
The exact process depends heavily on the migration tool you choose. Microsoft provides a native Cross-tenant SharePoint migration option for eligible organizations, while third-party tools can support projects that need different migration methods or more control over the move.
1. Review the Source Tenant
Start by reviewing the source SharePoint environment so you know exactly what you are working with before planning the move. Check the site types, storage usage, item counts, and any technical limits that could affect the migration.
Microsoft’s native cross-tenant migration supports several common SharePoint site types, including modern, classic, communication, and group-connected sites. However, site size, item count, and path-length limits still apply, so these should be checked before you build the migration plan.
2. Build a SharePoint Site Inventory
Once you understand the source environment, build a clear list of the sites that actually need to move. Do not assume every existing SharePoint site still belongs in the new tenant.
For each site, record its URL, owners, permissions, connected Microsoft 365 groups, external users, and any business processes that depend on it. You should also identify Power Automate flows, Power Apps, custom web parts, forms, and other integrations connected to the site.
This inventory often exposes old project sites, duplicate libraries, and unused content that no longer needs to follow users into the new environment. Removing that content before migration keeps the move smaller and makes post-migration validation easier.
3. Map Users, Groups, and SharePoint Permissions
Once the site inventory is clear, map the identities and permissions that need to carry over to the target tenant. This is one of the areas where tenant to tenant migration projects can become complicated.
A user in the old Microsoft 365 tenant and the same person in the new tenant are not technically the same identity. Even when the email address or display name looks familiar, SharePoint still needs a clear way to connect the source identity to the correct target account.
For Microsoft’s native process, you need to create the required users and groups in the destination tenant and map source identities to their target equivalents.
Pay particular attention to:
- Site owners and members
- SharePoint groups
- Microsoft 365 groups
- External users
- Directly assigned permissions
- Unique permissions on libraries, folders, or files
If someone still needs access after the migration but will remain outside the new tenant, you may need to create or map that person as a guest user.
Do not leave this work until after the content moves. Access issues often appear after migration when a user, group, or unique permission was missed during identity mapping.
4. Prepare the Target Tenant
Once the source sites, users, groups, and permissions are mapped, prepare the target tenant for the migration. Start by defining where each SharePoint site will go and confirm the new site URLs, naming conventions, owners, security groups, and target structure.
For Microsoft’s native cross-tenant process, this also includes establishing the required trust between the tenants, confirming compatibility, creating the required target identities, and preparing the identity mapping.
One important limitation affects how you build the destination environment. Microsoft’s native cross-tenant migration cannot move a SharePoint site into an existing target site and merge the content, so the destination site must not already exist.
This is why the migration method should be finalized before creating destination sites. We regularly come across target environments that need rework because sites were created before the migration approach was confirmed.
Also, confirm who controls the source and target tenants and assign responsibilities before cutover. Cross-tenant migrations often slow down when different teams need to complete identity, trust, permission, or configuration changes across the two environments.
5. Choose the Right SharePoint Migration Tool
There is no single tool that fits every SharePoint tenant to tenant migration. The right choice depends on the source environment, migration requirements, licensing, and how much control you need over the move.
Microsoft’s native Cross-tenant SharePoint migration keeps the transfer inside Microsoft 365 and can preserve important SharePoint elements such as permissions and redirects when the environment is prepared correctly. However, its availability and licensing requirements mean it will not suit every organization.
Do not confuse this feature with the SharePoint Migration Tool, commonly called SPMT. SPMT is mainly designed to move content into Microsoft 365 from sources such as on-premises SharePoint Server and file shares. It does not support SharePoint Online tenant-to-tenant migration.
For migrations that fall outside Microsoft’s native option, third-party tools can provide another route. Depending on the platform, they may offer migration scheduling, reporting, filtering, restructuring, or staged migration passes.
Before selecting a SharePoint-to-SharePoint migration tool, compare the options against your site volume, permissions, customizations, downtime requirements, reporting needs, and whether the migration requires multiple passes.
6. Run a Pilot Migration
Before moving production sites, run a pilot with a small set of SharePoint sites that represents the wider environment. The pilot should include more than a simple document library and cover the permissions, sharing settings, group memberships, and connected processes already present in the source tenant.
After moving the pilot sites, sign in with normal user accounts and test the migrated environment properly. Open documents, browse libraries, use navigation, follow shared links, and confirm that users can access only the content they should see.
Then test any workflows, forms, Power Apps, web parts, or integrations connected to those sites. This gives you a much clearer view of migration quality than relying only on a “completed” status in the migration dashboard.
Microsoft’s native cross-tenant feature works as a one-time move rather than an ongoing synchronization process, so the pilot should confirm that your mapping, permissions, and migration setup are ready before you begin the production cutover.
7. Move Production Sites in Controlled Batches
Once the pilot confirms that your mapping and migration method work, start the production migration.
For a larger environment, avoid moving every SharePoint site at once unless there is a strong reason to do so. Group sites into batches based on departments, business processes, ownership, or technical dependencies.
From the tenant-to-tenant migrations we have worked on, related SharePoint sites are easier to manage when they move together. Separating sites that share the same users, permissions, or business processes often creates avoidable access and coordination issues during cutover.
During Microsoft’s native migration process, the source site becomes read-only while the move takes place. After migration, redirects can help users who still open an old SharePoint link reach the content in its new tenant.
If SharePoint forms part of a wider Office 365 tenant to tenant migration, coordinate its timing with Exchange, Teams, OneDrive, identity, and domain changes. Moving these workloads in the wrong order can create access problems even when the SharePoint migration itself works correctly.
8. Validate the New SharePoint Environment
Once the production sites have moved, check both the migrated content and the components connected to it. Not everything associated with a SharePoint site automatically follows the content into another tenant, so these areas need separate validation.
Start with workflows and applications. Older SharePoint workflows may need to be recreated, while Power Automate flows and Power Apps can require new connections, permissions, or configuration in the destination tenant.
Custom web parts and integrations also need attention. Web parts linked to tenant-specific URLs, accounts, or services are among the components that often need updates after migration. Teams-connected sites require a similar check because moving the underlying SharePoint content does not migrate the complete Teams structure, channels, conversations, and settings.
Sensitivity labels and other compliance controls can also behave differently in the new tenant, so review protected or regulated content rather than assuming every policy will continue unchanged.
Next, validate the environment from the user’s perspective. Ask selected users from different permission levels to sign in and confirm that they can open the correct sites, libraries, folders, and files.
Then check navigation, search, sharing links, external access, group membership, web parts, Power Automate flows, Power Apps, forms, and integrations. Pay particular attention to content with unique permissions, as this is where mapping problems often become visible.
Finally, review any temporary configuration created for the migration, including cross-tenant trust settings, old redirects, migration accounts, and source-side access. Remove anything you no longer need once the target environment is stable and users have fully switched over.
How Code Creators Can Support Your SharePoint Tenant-to-Tenant Migration
A tenant-to-tenant SharePoint move becomes much easier to control when the source environment, user mappings, permissions, and target structure are reviewed before the migration starts. At Code Creators, we help organizations prepare that migration plan, identify dependencies that can affect the move, and choose an approach that fits the structure of their Microsoft 365 environment.
Our involvement can cover site assessment, identity and permission mapping, migration-tool selection, pilot testing, production cutover, and post-migration validation. We also review connected elements such as Power Automate flows, Power Apps, web parts, external access, and Microsoft 365 groups so the move does not stop at transferring files.
If you are preparing a SharePoint tenant to tenant migration and want to understand the safest way to move your sites, permissions, and connected processes, schedule a consultation with our team to review your migration requirements and plan the next steps.
Conclusion
A SharePoint tenant to tenant migration works best when you handle the dependencies before moving the content. Start with a complete site inventory, define the target structure, map users and permissions carefully, and choose the migration tool before building the destination environment.
Microsoft’s native cross-tenant option can provide a direct route between eligible Microsoft 365 tenants, but it comes with specific requirements and does not work like a general-purpose synchronization tool. SPMT does not support SharePoint Online tenant-to-tenant moves, so organizations that cannot use the native option may need a dedicated third-party migration platform.
Whichever route you choose, identities, permissions, workflows, connected services, and post-migration access need careful attention throughout the move. If you need support planning or carrying out the migration, explore our SharePoint migration services to move your sites and related content to the new tenant with fewer disruptions.
