You have just completed an acquisition. The combined organisation now has two active Microsoft 365 tenants, and IT has 90 days to consolidate. Sixty of the source company's SharePoint sites need to move to the destination tenant, complete with document libraries, metadata, version history, and the folder structures that teams have built up over years. No native Microsoft tool handles cross-tenant site migration at scale. This guide walks through how to approach it using ShareMaster Clone Master.
What a Cross-Tenant Migration Actually Involves
Moving SharePoint content between two separate Microsoft 365 tenants is fundamentally different from moving files within the same tenant. Within a tenant, user identities, content types, and permission structures are shared across sites. Across tenants, those things belong to separate Entra ID directories and separate SharePoint environments. Understanding the differences upfront prevents surprises mid-project.
| Aspect | Within-tenant move | Cross-tenant migration |
|---|---|---|
| Tool | SharePoint native Move To, or ShareMaster Copy To / Move To | Clone Master |
| User identity mapping | Same identity store; permissions resolve automatically | Different Entra ID directories; user assignments need manual review post-migration |
| Version history | Supported by ShareMaster Copy To / Move To | Supported by Clone Master (configurable) |
| Lists and metadata | Supported | Supported; destination columns must exist before migration |
| Sharing links | Not migrated (links are tenant-specific) | Not migrated |
| Admin access required | Source site admin | Admin access on both source and destination tenants |
Before You Start
These prerequisites should be confirmed before any migration work begins:
- A Windows machine available to run ShareMaster throughout the migration window.
- SharePoint admin (or site collection admin) access on the source tenant.
- SharePoint admin (or site collection admin) access on the destination tenant. If you are a consultant, coordinate with the client's Microsoft 365 admin to secure this in advance.
- The destination site collection either already created, or a plan for Clone Master to create it.
- Custom columns and content types on the destination site libraries match those on the source. Column values for fields that do not exist at the destination are dropped during migration.
- A written inventory of what will be migrated (see Step 1).
Step 1: Inventory the Source Site
Before connecting any tool, document what you are migrating. A structured inventory reduces surprises during the migration run and gives you a concrete checklist to verify against at the destination.
For each site to be migrated, record:
- All document libraries: names, custom columns (internal and display names), content types in use, and any views that matter to users.
- All custom lists: structure, column types, and approximate item counts.
- Libraries or lists with broken permission inheritance (unique permissions). These are the most complex to verify post-migration.
- Approximate file count and total storage volume per library. This calibrates how long the migration will take.
- Any files that are currently checked out. Checked-out files cannot be read by migration tools and will produce per-item errors unless checked in or discarded first.
A spreadsheet with one row per library, columns for unique permissions (yes/no), custom content types (yes/no), approximate file count, and approximate size, takes 30 minutes to fill in. It saves hours of post-migration investigation.
Step 2: Connect Clone Master to Both Tenants
Authenticating to the source tenant
Install ShareMaster on the Windows machine that will run the migration. Open Clone Master and add a new connection for the source tenant. Enter the source tenant's SharePoint URL and authenticate using your source admin account. Clone Master uses the Microsoft identity platform for authentication: you will be directed to sign in via your browser and grant the necessary permissions. The connection is stored so you do not need to re-authenticate on every session.
Authenticating to the destination tenant
Add a second connection for the destination tenant following the same process, using an admin account on the destination tenant. Both connections are visible in Clone Master simultaneously, which is what enables cross-tenant migration: Clone Master reads from the source connection and writes to the destination connection in the same job.
Test each connection independently before starting the main migration. Confirm that Clone Master can browse the source site's document libraries and that it can create or read the destination site. Discovering a permission or connectivity issue at the start of a migration run wastes the migration window.
Step 3: Select Sites and Configure the Migration Job
With both tenants connected, select the source site or sites to migrate. For a cross-tenant project, you will typically map each source site collection to a corresponding destination site collection.
Files and version history
Configure Clone Master to include file content. Whether to include version history is a project decision: version history is important when document audit trails and rollback capability are a business requirement. Including full version history increases migration time proportionally to the number of versions stored per file. SharePoint Online stores up to 500 major versions per file by default. A library with 5,000 files at an average of 100 versions each is a materially larger migration than the same library without version history.
If migration time is the primary constraint, consider migrating only the current version plus a limited number of recent versions. Balance the business value of historical versions against the time window available.
Metadata and content types
Clone Master migrates column values as part of the migration job. For metadata to arrive at the destination correctly, the destination library must have matching columns with the same internal names as the source. If a destination library is missing a column, Clone Master silently drops the corresponding metadata values. Create any required custom columns on the destination site before the migration run, using your inventory from Step 1 as the reference.
Content types follow the same rule: a content type referenced on a source file must exist in the destination site's content type hub or site content type gallery before migration. Migrating content where the destination is missing the referenced content type produces fallback behaviour where SharePoint assigns it a default content type. Review your inventory and replicate any custom content types on the destination tenant in advance.
Permissions
Clone Master migrates the permission structure from the source site: which groups exist, which permission levels those groups hold, and any unique permissions on libraries or items. What it cannot do automatically is resolve source tenant user accounts to equivalent accounts on the destination tenant, because those accounts are in separate Entra ID directories. A permission entry for alice@sourcecompany.com on the source site has no automatic counterpart on the destination tenant unless alice has an account there.
Plan for a permission review step after migration completes. The permission structure Clone Master migrates gives you a clear picture of what needs to be re-assigned. Destination tenant admins can then re-map group memberships and unique permission entries to the correct accounts on the new tenant.
Step 4: Run the Migration and Monitor Progress
Start the migration job. Clone Master displays a progress panel showing completed items, current throughput, and any per-item errors. For large sites, cross-tenant migrations run for hours. Clone Master operates as a Windows desktop application, so the job is not subject to browser session timeouts. If the machine running Clone Master goes to sleep or loses connectivity, the job can be resumed.
SharePoint Online throttles API requests when they exceed its rate limits. Clone Master handles this automatically - it detects the 429 response, waits for the retry interval SharePoint specifies, and resumes the job. No rate-limit configuration or manual 429 monitoring required.
Common causes of per-item errors to watch for during the run:
- Checked-out files: files that were checked out on the source and not checked in before the migration. These cannot be read by the migration tool. Check them in on the source tenant and re-run for those items.
- Missing content types: a file references a content type that does not exist on the destination. Create the content type on the destination and re-run affected items.
- Filename characters: some special characters in file names behave differently across SharePoint environments. Files with problematic names will produce errors in the progress panel with the specific file path.
Step 5: Verify the Results and Follow Up
After the migration job completes, verify the destination before communicating to users or decommissioning the source.
- File count at the destination matches the source for each migrated library.
- A sample of files opens correctly and shows the expected metadata column values.
- Version history is present on files where it was included in the migration job.
- Lists and their items are present with correct column structure.
- Site navigation and page content are intact.
- Permissions have been reviewed and re-mapped to destination tenant user accounts.
Two post-migration tasks that often get left until too late:
- Update hardcoded source URLs. Documents, site pages, and list items frequently contain links pointing to the source tenant URL. Those links break after the source is decommissioned. ShareMaster's Replace Master can find and replace the old tenant URL across document libraries and Site Pages at scale, without opening each file individually.
- Keep the source in read-only mode for a grace period. Retain source content as read-only for two to four weeks after migration. Users who missed the communication, or who have bookmarks to source URLs, will encounter the content rather than a 404. This grace period gives you time to catch any access requests that point to the old location.
For context on how Clone Master compares to other SharePoint migration tools, see the Clone Master vs ShareGate vs Migration Manager comparison.
Frequently Asked Questions
How long does a cross-tenant SharePoint migration take?
Duration depends primarily on file count, file sizes, and whether version history is included. A site with 10,000 files and no version history might complete in one to two hours. The same site with full version history at hundreds of versions per file could run for many hours. Run a test migration on a small library first to calibrate timing before scheduling the production window.
Does Clone Master preserve version history in a cross-tenant migration?
Clone Master migrates version history when this option is configured for the migration job. Version history appears in the file's history list at the destination after the migration completes. Including full version history substantially increases migration time, so weigh the business requirement for historical versions against the available migration window.
What happens to SharePoint permissions in a cross-tenant migration?
Clone Master migrates the permission structure from the source: site groups, their permission levels, and any unique permissions on libraries or items. User-level permission entries reference accounts in the source tenant's Entra ID. Because those accounts exist in a different directory from the destination tenant, user assignments need to be reviewed and re-mapped to the correct destination accounts after migration. The migrated permission structure from Clone Master gives the destination admin a clear reference for that work.