Cross-tenant SharePoint migrations fail more often from missing prerequisites than from tool issues. This reference covers what needs to be in place before the first migration run.
| Category | Requirement | Notes |
|---|---|---|
| Admin role - source tenant | SharePoint Administrator or Global Administrator | Required to access all site collections and manage tenant-level settings |
| Admin role - destination tenant | SharePoint Administrator or Global Administrator | Required to create sites, assign permissions, and configure storage |
| Microsoft 365 licence - source | Any plan that includes SharePoint Online | Source plan must remain active throughout the migration; do not let it lapse mid-run |
| Microsoft 365 licence - destination | Compatible plan with sufficient SharePoint storage quota | Users need licences assigned before they can access migrated sites post-cutover |
| Destination sites | Sites and libraries pre-created at destination | Migration tools write into existing structures; they do not provision sites from scratch |
| Content types | Required content types must exist at destination before migration starts | If a content type is absent, items land under the default library content type |
| Term store (managed metadata) | Matching terms pre-created in destination term store | Cross-tenant term stores are separate; missing terms cause managed metadata to migrate as plain text |
| User mapping | Mapping file or list of source-to-destination account pairs | Without this, Created By, Modified By, and People columns default to the migration service account |
| Storage quota | Destination tenant has sufficient quota before migration starts | SharePoint storage is pooled at tenant level; verify via SharePoint admin center before starting |
| Migration machine | Windows PC or server with internet access and admin credentials for both tenants | Clone Master is a desktop tool; the machine must maintain a stable connection throughout the run |
What admin permissions does a cross-tenant SharePoint migration require?
Both tenants require SharePoint Administrator or Global Administrator access. The admin credentials used at the source must cover all site collections in scope. At the destination, that same access level covers creating library structures, assigning permissions, and configuring site settings. Two separate authenticated sessions running simultaneously is the normal operating state for a cross-tenant migration tool.
If a consultant or MSP is running the migration on behalf of a client, both the client's admin credentials and the service provider's credentials may need to be involved at different stages. The cleanest approach is a dedicated migration service account in each tenant, assigned SharePoint Admin permissions for the duration of the project and revoked immediately after migration completes.
For a full walkthrough of preserving permissions themselves during migration, see the guide to preserving SharePoint permissions during migration.
Tenant settings to check before migration
Two tenant-level settings have the most direct impact on migration outcomes:
- SharePoint storage quota at the destination. Check the current usage and available quota in the SharePoint admin center before starting. Export a storage breakdown by library from the source to size the destination requirement accurately. The library-level storage report guide covers how to produce this export using Report Master.
- Site creation permissions at the destination. If destination sites need to be created during the migration project, confirm that site creation is not restricted in the destination tenant's SharePoint admin center. A restricted creation policy requires Global Admin involvement each time a site is provisioned, which adds delays if sites are being created during the run.
Pre-migration checklist
- Identify all source site collections and libraries in scope. Export a site inventory using Report Master to capture sizes, owner names, last activity dates, and storage usage per library.
- Create all destination site collections and libraries with the correct templates and hub associations.
- Replicate the source content type structure at the destination, or confirm that existing destination content types match the source.
- If managed metadata columns are in use, create matching terms in the destination term store before the migration run. Document which terms map to which for validation after cutover.
- Prepare a user mapping file that links source user principal names to destination user principal names. Test it against a small pilot library before scaling up.
- Verify destination storage quota is sufficient for all migrated content plus any existing data already at the destination.
- Run a test migration against one representative library. Confirm column values, content types, and Created By and Modified By fields are accurate before starting the full run.
- Schedule the final delta run and the source-side read-only lock for a low-activity window. Communicate the cutover date to affected users at least one week in advance.
Frequently Asked Questions
Do I need the same Microsoft 365 licence in both tenants for a cross-tenant SharePoint migration?
The source tenant needs a Microsoft 365 plan that includes SharePoint Online, and it must remain active throughout the migration. The destination tenant needs a compatible plan with enough storage quota for the migrated content. Users at the destination need licences assigned before they can access migrated sites after cutover. The migration tool itself runs under admin credentials and does not require a per-user licence for the migration process.
Does the destination tenant need to allow external sharing for the migration to work?
No. Migration tools authenticate via admin API calls, not through end-user sharing links. External sharing settings govern what links users can send, not what admins can access via API. You do not need to change the destination tenant's external sharing settings to enable a migration tool to connect and write content.
Can I run a cross-tenant SharePoint migration while source sites are still in use?
Yes, live migration is possible, but changes made to source documents after the initial pass will not automatically appear at the destination. The standard approach is a bulk initial pass followed by a delta pass close to the cutover date to catch changes made during the migration window. Set source sites to read-only during the final delta run to prevent conflicts.
For the full step-by-step walkthrough, see how to migrate a SharePoint site to another tenant.