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. Microsoft does have a native option, Cross-tenant SharePoint migration, but it is sold only to Enterprise Agreement customers and licensed per 100 GB moved, it runs from PowerShell, and it moves each site once, with no incremental passes and no merging into a site that already exists. This guide walks through the alternative 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, or Microsoft's Cross-tenant SharePoint migration (Enterprise Agreement licence, PowerShell) |
| User identity mapping | Same identity store; permissions resolve automatically | Different Entra ID directories; pair source and destination accounts in a user mapping, then review |
| Version history | Supported by ShareMaster Copy To / Move To | Supported by Clone Master (configurable) |
| Lists and metadata | Supported | Supported; Copy structure and content creates the lists, columns and content types at the destination |
| Sharing links | Not migrated by ShareMaster | Not migrated by ShareMaster (Microsoft's own cross-tenant move redirects them) |
| 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 the copy to create it.
- A decision on structure: Copy structure and content builds the lists, columns and content types at the destination for you. If you copy content into lists you built yourself, their columns must match the source's internal names.
- 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. Edits made during a checkout are not visible to anyone else until the file is checked in, and a file that has never been checked in can be invisible to the migration account altogether, so ask owners to check files in 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.
While you are inventorying, flag any Project Web App sites separately rather than adding them to the migration list. PWA sites hold project schedules, resource pools and custom fields in a data model of their own, so what a site-level copy moves across is the SharePoint layer around the project data rather than the project data itself. They also sit behind a deadline that has now passed: Project Online was retired on 30 September 2026. Handle any that remain on their own track, starting with what happens to Project Online data after retirement and saving what you can from a PWA site that still opens.
Step 2: Connect ShareMaster to Both Tenants
Authenticating to the source tenant
Install ShareMaster on the Windows machine that will run the migration. Open Copy & Move and choose Copy structure and content. Enter the source site's URL and sign in with your source admin account in the Microsoft sign-in window that opens. The connection is kept in ShareMaster's list of current connections, so you can pick it again later in the session.
Authenticating to the destination tenant
Next, enter the destination site's URL and sign in the same way with an admin account on the destination tenant. ShareMaster then shows the source and destination side by side, which is what enables cross-tenant migration: it reads from the source connection and writes to the destination connection in the same job. Because the two tenants cannot copy server-side between each other, the content is downloaded to the machine running ShareMaster and uploaded through Microsoft's migration API, so give that machine a reliable connection and free disk space for temporary files.
Test each connection independently before starting the main migration. Confirm that ShareMaster 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
File content is always copied. 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, turn off Retain all versions in the copy options and set the Number of versions to retain; zero copies only the current version and is the fastest. Balance the business value of historical versions against the time window available.
Metadata and content types
ShareMaster migrates column values as part of the job. With Copy structure and content, it creates each list and library on the destination with its columns, views and content types before copying the items, so the metadata has somewhere to land. If you instead copy content into lists you built yourself, each column needs the same internal name and type as the source, so use your inventory from Step 1 as the reference.
Lookup columns need their related lists. The options include creating missing lookup lists and filling them, and matching lookup values by value or by ID. Check these before a site with many related lists, since a lookup that cannot find its target list is skipped.
Permissions
With Copy all permissions on, ShareMaster copies the permission structure from the source site: permission levels, SharePoint groups, and any unique permissions on libraries or items. The accounts behind those permissions live in separate Entra ID directories, so a permission entry for alice@sourcecompany.com on the source site has no counterpart on the destination tenant unless you say who Alice is there.
That is what the user mapping is for: before the copy, pair each source account with its destination account (for example alice@sourcecompany.com with alice@newcompany.com). Create the destination accounts first. Plan for a permission review after migration completes for anyone you did not map.
Step 4: Run the Migration and Monitor Progress
Start the migration job. ShareMaster displays a progress panel showing each item and any per-item errors. For large sites, cross-tenant migrations run for hours. ShareMaster is a Windows desktop application, so the job is not subject to browser session timeouts, but keep the machine awake: if it sleeps or loses connectivity, re-run the copy. A whole-site copy records which stage it reached and offers to continue from there, and the Skip file/item if exists at destination option stops files that already arrived from being copied again.
SharePoint Online throttles API requests when they exceed its rate limits. ShareMaster handles this automatically: it detects the 429 response, waits, and retries. 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. Check them in on the source tenant and re-run for those items.
- Path length: SharePoint allows up to 400 characters in a decoded path. A longer site or library URL at the destination can push deep folder paths over that limit; shorten the destination URL or the folder names.
- 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 site by site, in column values, list settings and the content of pages and Office files, without opening each file individually. The copy options can also replace values in metadata as the content is copied.
- 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?
Yes. The copy options let you keep every version or a set number per file, and the versions appear 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?
With Copy all permissions on, ShareMaster copies the permission structure from the source: permission levels, SharePoint groups, and any unique permissions on libraries or items. User-level entries reference accounts in the source tenant's Entra ID, so you pair each source account with its destination account in the user mapping before the copy, then review the result for anyone you did not map.
Learn more about Clone Master. A trial licence skips items at random intervals by design, so use it to rehearse on a small site rather than for the real move.