Version history alone can add five times the visible file size to a cross-tenant migration. An 80 GB document library with active versioning can require 400 GB to transfer, and that number determines whether you finish in an evening or spend a week troubleshooting a mid-job quota error on the destination tenant. This guide covers every step from pre-migration audit to post-migration sign-off.
What migrates and what does not
Several common items migrate with limitations or not at all - knowing which before you start avoids surprises at sign-off.
| Item | Migrates? | Notes |
|---|---|---|
| Files and nested folder structure | Yes | All files including subfolders replicated to destination |
| Custom column values (metadata) | Yes, if columns exist in destination | Create matching columns in the destination library before running the migration |
| Version history | Yes | Trim first to control transfer volume; see Step 2 |
| Library permissions (broken inheritance) | Partially | Permissions matching destination security groups are preserved; source-tenant accounts are flagged for manual review |
| Sharing links | No | Cross-tenant sharing links are tenant-specific; revoke them before migrating |
| Content types | Yes, if types exist in destination | Publish required content types to the destination site collection hub before the job starts |
| Column default values | Yes | Library-level column defaults transfer with the library configuration |
Step 1: Audit the source library before touching anything
A thorough pre-migration audit takes 20 minutes and prevents hours of cleanup after the fact. Connect ShareMaster to the source tenant and run Report Master against the target library - the Excel export gives you file counts, storage breakdown, and permission status in a single pass, covering everything the downstream decisions depend on.
Check the storage breakdown
The report separates live content storage from version history storage and recycling bin usage. If version history exceeds 30 to 40 percent of the total, trimming before migration is not optional - it is the single most impactful thing you can do to reduce transfer time and cost.
Note the largest individual files. A single 10 GB video or CAD archive can dominate a migration window on its own. Knowing those outliers in advance lets you schedule the job accordingly rather than discovering them halfway through.
Audit and revoke sharing links
Sharing links created in the source tenant reference URLs specific to that tenant's domain. After migration, those links point nowhere. More critically, any active guest access associated with those links could carry over as metadata that creates confusion in the destination permission picture.
Use the Shared Links and Permissions tool to enumerate all active sharing links on the library. Export the list, confirm with the content owner which links are still needed, and bulk-revoke the remainder directly from ShareMaster before the migration starts. This takes 10 minutes and eliminates a class of post-migration permission questions entirely.
Step 2: Trim version history before migrating
Most SharePoint libraries accumulate version history without a cap. A library of 10,000 documents that has been actively used for three years can hold 50 or more versions per file. The math adds up fast: 50 GB of live content with 40 versions per document becomes 2,000 GB to transfer.
Open Space Master and run the Version Trimmer on the source library. Set a keep count that makes sense for the content type. For general document storage: 10 to 20 major versions. For libraries used for formal document control records: confirm the retention requirement with the business owner before trimming.
After trimming, run Report Master again to capture the updated storage figure. That post-trim number is what you will actually transfer - and it tells you whether the destination tenant has sufficient quota headroom before you start the job.
Step 3: Prepare the destination site and library
Cross-tenant migrations are cleaner when the destination site and library already exist with the right structure in place. Do this before opening Clone Master.
- Create the destination site and library. Match the library name and URL where possible to reduce post-migration link updates. If Replace Master is part of your toolset, you can fix URL mismatches after the fact, but eliminating them upfront is simpler.
- Add all custom columns. For each column in the source library, create a matching column in the destination with the same internal name and column type. Column order does not need to match, but the internal names must.
- Publish content types. If the source library uses content types from a content type hub, publish the equivalent types to the destination site collection before the migration starts. Files whose content type does not exist in the destination will still migrate but fall back to the default type.
- Confirm destination quota. Check available storage headroom against the post-trim migration size. Leave at least 20 percent margin above the expected transfer volume. If the destination is close to its limit, address that before starting: running out of quota mid-job creates a partially migrated library that is difficult to reconcile cleanly.
Step 4: Run the cross-tenant document library migration with Clone Master
Both tenants must be accessible from the same Windows machine running ShareMaster. Open Clone Master and authenticate to the source and destination tenants.
- Select the source site and then the document library within it.
- Select the destination site and map it to the corresponding library.
- Review metadata mapping, permission handling, and version history scope settings.
- Start the migration job.
Clone Master is resume-safe. If the job is interrupted by a network drop or machine restart, simply restart it. The tool continues from the last completed file without re-transferring anything already done.
For large libraries, schedule the job to run overnight or across multiple evenings to avoid bandwidth competition with business users. SharePoint throttles sustained high-volume API traffic, so running during off-peak hours reduces the chance of 429 responses slowing throughput. For detail on how throttling works and how to respond to it, see the SharePoint migration throttling limits reference.
Step 5: Verify results and sign off
After Clone Master reports the job complete, verify before decommissioning anything on the source side.
Run Report Master against the destination library. Compare the file count and storage total to the post-trim figures from Step 2. A meaningful mismatch - more than a few percent on either metric - warrants investigation before proceeding. Spot-check five to ten documents from different folders: open each in SharePoint Online, confirm the current version content is correct, check that custom column values are present, and verify the version history list contains the expected number of entries.
Bring in a business user who works regularly with the library for a brief acceptance check. An admin verifying file counts is not the same as a content owner confirming that a key document's metadata and version history look right. Both checks serve different purposes and together provide a solid basis for signing off.
Once verified, revoke remaining source access, update any navigation or search links pointing to the old library URL, and leave the source library in read-only mode for an agreed handover period before decommissioning it.
Frequently Asked Questions
Does Clone Master preserve metadata when migrating a SharePoint library cross-tenant?
Yes. Clone Master copies custom column values, content types, and library configuration alongside the files. Metadata maps automatically to matching columns in the destination. Columns that exist in the source but not the destination need to be created in the destination library before the migration runs.
What happens if a cross-tenant SharePoint migration is interrupted?
Clone Master is resume-safe. If the job is interrupted by a network drop, machine restart, or manual pause, restart it and it picks up from the last completed file. Files already transferred are not re-copied, so there will be no duplicates in the destination.
Should I trim version history before migrating cross-tenant?
In almost all cases, yes. Version history multiplies effective data volume significantly on actively edited libraries. Trimming to 10 to 20 major versions before migration is one of the highest-return preparation steps available. It cuts transfer time, reduces destination storage cost, and eliminates the risk of hitting the destination tenant's quota mid-job.
What admin permissions are needed for a cross-tenant library migration?
SharePoint Administrator rights on both tenants, or at minimum Site Collection Administrator access for the specific sites on each side. Global Administrator access covers all required permissions on both source and destination.