Meet Daniel, a SharePoint administrator at a mid-sized managed service provider. His MSP manages Microsoft 365 environments for around 40 small-to-medium business clients across Australia and New Zealand. Daniel's team handles migrations, licensing, and ongoing tenant health for all of them.
The situation
Two of Daniel's clients, a construction firm called Bridgepoint and a materials supplier called Crestfield, announced a merger. Both companies ran independent Microsoft 365 tenants with active SharePoint Online environments. The deal closed in six weeks, and the business wanted all content under the Bridgepoint tenant by end of the following quarter.
The Crestfield tenant had to be fully decommissioned: licences cancelled, mailboxes migrated to Exchange, and SharePoint content moved into Bridgepoint's existing site structure. Daniel's team would handle the SharePoint side.
What Crestfield's SharePoint environment looked like
- 14 team sites, mostly using default permissions with a few sites broken to unique permissions at the library level.
- Approximately 280 GB of content across all sites, but version history added another 390 GB on top of that.
- Six years of active use, with some libraries having 300 to 400 versions per file from frequent editing.
- Several shared links sent to external parties that needed to be audited and revoked before decommission.
- A mix of document libraries, lists with custom columns, and a few classic publishing pages.
Daniel's first instinct was to start migrating immediately. His second instinct, after running a quick storage report, was to stop and do the math. Moving 670 GB cross-tenant would take many hours, and if the destination hit quota mid-job, he would have a partially migrated environment and an unhappy client.
Phase 1: Audit and plan with Report Master
Understand what you are moving before moving it
Daniel connected ShareMaster to the Crestfield tenant and ran Report Master across all 14 sites. The Excel export gave him:
- Total storage per site, broken down by live content vs. version history vs. recycling bin.
- Version counts and average version age per library.
- A permission matrix showing which sites and libraries had broken inheritance.
- File type distribution, flagging large video files in two sites that could be moved to SharePoint assets or Stream instead of being migrated as documents.
The report confirmed what Daniel suspected: version history represented 58% of the total storage volume. Three libraries alone accounted for most of it, each with versioning enabled and no version limit set.
Phase 2: Clean up storage with Space Master
Trim before you transfer
Before migrating a byte, Daniel used Space Master to reduce the data volume to a manageable size.
Version Trimmer: Daniel set a keep policy of 15 major versions per file across all 14 sites. The trim ran overnight. The next morning, the version storage had dropped from 390 GB to approximately 55 GB. The three heavy libraries went from combined version storage of over 250 GB to under 40 GB.
Empty Folder Remover: Crestfield's sites had accumulated hundreds of empty folders from past reorganisations. Removing them before migration avoided cluttering Bridgepoint's new site structure with artefacts from six years of folder shuffling.
Recycling Bin: Daniel ran a tenant-wide Recycling Bin clear using Recycle Master after confirming with the client that no deleted content needed recovery. This removed another 30 GB from the migration scope.
After the cleanup phase, the effective migration scope dropped from approximately 670 GB to around 310 GB. That is less than half the original size, and it fit comfortably within Bridgepoint's available tenant storage quota without requiring an emergency storage purchase.
Phase 3: Audit and revoke external sharing
Don't migrate shared links you no longer control
Crestfield had been sharing documents with external suppliers and contractors using shareable links. Some of those links were still active and pointed to files that were about to move tenant. If migrated without revoking, the old links would break anyway (they reference the source tenant's URLs), but the sharing metadata would travel with the content and confuse the permission picture on the destination.
Daniel used the Shared Links and Permissions tool to enumerate all active sharing links across all Crestfield sites. The report listed 1,240 unique links, with 180 still active for external recipients. He exported the list, shared it with Crestfield's IT manager for review, and then bulk-revoked the confirmed inactive or unneeded ones directly from ShareMaster. The client's IT manager handled the remaining handful that needed individual communication first.
Phase 4: Cross-tenant migration with Clone Master
Moving content between two live tenants
With cleanup done, Daniel opened Clone Master and connected both tenants simultaneously: Crestfield as source, Bridgepoint as destination. He mapped each Crestfield site to its new home in Bridgepoint's site structure, which the Bridgepoint IT lead had pre-created with the right names and base permissions.
Clone Master migrated each site in sequence, transferring files, metadata, custom column values, and library configurations. Broken-inheritance permissions at the library level were preserved where they matched existing Bridgepoint security groups, and flagged for manual review where they referenced Crestfield-specific accounts.
The migration ran across three evenings to avoid bandwidth impact during business hours. On the second evening, Daniel's laptop lost network connectivity briefly. Clone Master's resume-safe transfer picked up from the interrupted file on the next run without re-copying anything already completed.
Phase 5: Post-migration verification
After all 14 sites were copied, Daniel ran Report Master again, this time against the Bridgepoint tenant, to confirm that storage counts matched expectations and that no site had silently failed to receive its content. He also spot-checked five randomly selected documents per site by opening them in Bridgepoint to verify metadata, version history, and file integrity.
The client's IT manager ran a business-user acceptance test across the most heavily used libraries. No content gaps were reported. The migration was signed off within the agreed timeline.
Results
| Metric | Before cleanup | After cleanup and migration |
|---|---|---|
| Total data scope | 670 GB | 310 GB migrated |
| Version storage | 390 GB | 55 GB (15-version keep policy) |
| Active external sharing links | 180 active | 0 (all revoked before migration) |
| Additional storage purchase required | Would have needed ~400 GB | None |
| Sites migrated | 14 | 14 (100%) |
| Migration interruptions handled | 1 (network drop) | Resumed automatically, no rework |
What made the difference
The cleanup phase was the deciding factor. Without it, Daniel would have been migrating 670 GB of data, potentially requiring an emergency storage top-up on the Bridgepoint tenant and significantly longer migration windows. By auditing first with Report Master, trimming with Space Master, and revoking sharing links before touching the migration, the job was smaller, cleaner, and faster than the original estimate.
For MSPs running multiple client migrations each year, this pattern (audit, trim, clean, then migrate) consistently reduces the time and cost per engagement. The tools are the same whether you are consolidating two tenants or relocating content within one.