Sarah got the call on a Tuesday morning in early spring. The management buyout she and her colleagues had worked toward for eight months had just closed. The firm was independent. And as IT director for the newly separated wealth management business, she had 90 days to move the company's entire Microsoft 365 environment out of the parent banking group's tenant before the transition service agreement expired.
The firm had been running inside the parent company's Microsoft 365 tenant for six years. Twelve advisers, two analysts, a compliance team, and a back-office function: about 75 people in total. Their SharePoint environment held six years of client engagement records, internal workpapers, regulatory filings, HR documents, and a collection of archived project sites from concluded matters. None of it could stay in the parent tenant once the separation was formalised.
The 90-day window was non-negotiable. It was written into the transaction agreement. Sarah had never run a SharePoint cross-tenant migration before. She knew what Clone Master could do for migrations within a tenant; this was the first time the firm needed it to move content across to an entirely new tenant.
The challenge: taking stock of six years of unplanned SharePoint growth
The first problem Sarah faced was that nobody had a current picture of what was in the SharePoint environment. The tenant had grown organically: sites created for individual client matters, ad hoc document libraries set up by advisers, HR folders nested inside general admin sites. There was no site naming convention, no decommissioning process for closed matters, and no record of which external guests had been granted access over the years.
Before she could plan a migration, she needed a complete inventory. She ran Report Master against the tenant to generate two reports: a site inventory listing every site collection with its owner, last activity date, and total storage, and a permissions matrix showing every user and group with access across all sites.
The inventory returned 76 site collections. The permissions report identified 23 external guest accounts, of which 17 were from former clients whose engagements had concluded more than a year earlier. Neither number was surprising in isolation, but seeing them in a single export made the scope of the cleanup immediately legible.
Building the content inventory: what exists and what is worth migrating
Not everything in the tenant needed to move to the new one. Some archived sites held completed matter files that were subject to retention requirements but were unlikely to be accessed again; those could be archived rather than migrated. Identifying which content fell into which category was the second big task before the migration could start.
Sarah worked through the site inventory with the firm's compliance officer and practice manager, categorising each site by content type and business priority. The result:
| Content category | Site count | Estimated file volume | Migration priority |
|---|---|---|---|
| Active client engagement records | 28 | ~38,000 files | First wave (weeks 1-4) |
| Internal workpapers and analysis | 15 | ~11,000 files | First wave (weeks 1-4) |
| HR, finance, and operations | 9 | ~4,000 files | Second wave (weeks 5-7) |
| Completed and archival matters | 24 | ~72,000 files | Selective: archive compliance-required; skip the rest |
The archival matters category was the largest by file count but the lowest priority for live access. The firm decided to export the files they were legally required to retain as a structured archive and not recreate those 24 sites in the new tenant at all. That decision alone cut the active migration scope from 125,000 files to around 53,000.
Pre-migration cleanup and the migration itself
Before running a single migration job, Sarah tackled two cleanup tasks that would otherwise have inflated the data volume and complicated the post-migration state.
First, she revoked the 17 stale external guest accounts using the Shared Links and Permissions tool. This cleared all their sharing link grants and site-level permissions. The banking group's IT team then removed the 17 accounts from the parent tenant's Entra ID as part of the separation process. Starting the new tenant without inherited guest access was a clean baseline from a compliance standpoint.
Second, she ran Space Master's Version Trimmer against the active client engagement libraries before the migration. The version history on the active matter sites had grown substantially: files co-authored by multiple advisers over years of work had accumulated hundreds of versions each. Including the full version history in the migration would have more than doubled the data volume. She applied a keep policy of 30 most-recent major versions per file, which preserved the practically relevant version history while reducing the pre-migration storage footprint of the first-wave sites by approximately 40 percent.
The first-wave migration ran as a series of Clone Master jobs over four weeks, moving the 28 active client matter sites and 15 internal workpaper sites to the new tenant. Each job was configured to recreate the source library structure, carry the trimmed version history, and remap permissions to the provisioned destination accounts. The migration ran overnight to avoid impacting access during business hours. Staff continued working in the source tenant during the migration and switched to the destination tenant for active matter sites as each job completed.
The second-wave HR and operations sites migrated in week five. By week seven, 53 of the 76 original sites were live in the new tenant, the remaining 23 archival sites had been exported as file packages for compliance retention, and the firm formally vacated the parent tenant before the 90-day deadline.
Try ShareMaster free for 14 days
What the firm learned from a hard-deadline SharePoint split
Three things made the 90-day deadline achievable. The content inventory came first. Without the site inventory and permissions report from Report Master in week one, the triage meeting with the compliance officer and practice manager would have taken weeks to work through informally. The structured data made a three-hour meeting possible that resolved every classification question.
The decision not to migrate the archival matter sites was the single biggest schedule risk reduction. Cutting 72,000 files from the scope in week one compressed the active migration to a volume that a small IT function could manage without external consultants.
The version trim before migration was worth more than it first appeared. A 40-percent reduction in pre-migration storage translated directly into faster jobs, smaller overnight windows, and lower risk of a timeout or partial failure during the migration runs. The guide on migrating a SharePoint site to another tenant covers the full migration process in step-by-step detail, including how to set up user mappings and configure the Clone Master job settings for a cross-tenant move.
Six months after the transition, the firm's new tenant is clean by design rather than by accident. The site naming convention and decommissioning process they put in place during the migration planning are in production, and every new client matter site is created from a template with a defined owner and a documented closure workflow.
Frequently Asked Questions
What SharePoint content does not transfer automatically in a cross-tenant migration?
Permissions do not transfer automatically. User accounts in the source tenant do not exist in the destination until provisioned there, so permission assignments must be remapped to corresponding destination accounts. SharePoint groups, unique permission grants, and sharing links all require explicit handling during or after the migration. Clone Master uses a user mapping file to recreate permission grants in the destination tenant.
How long does migrating 50,000 SharePoint files across tenants typically take?
Speed depends on file sizes, version history depth, and network throughput. For 50,000 files with moderate version history and typical file sizes, a cross-tenant migration typically completes within a few days of running time when run overnight. Trimming version history before migrating significantly reduces both data volume and migration duration.
Can SharePoint permissions be preserved during a cross-tenant migration?
Permissions can be recreated in the destination tenant using a user mapping, but they cannot be directly copied because source tenant accounts do not exist in the destination. Clone Master maps source permission grants to destination user accounts and recreates the permission structure, provided destination accounts are provisioned and a mapping file is prepared before the migration runs.
What happens to version history when you migrate SharePoint files to a new tenant?
Version history can be carried across in a cross-tenant migration if the migration tool supports it. Including full version history significantly increases migration data volume. Trimming version history in the source first reduces the data transferred and the time each migration job takes to complete.