The semester break window was 14 weeks. Marcus Adeyemi, IT Director at Coastal University in Queensland, needed to move 43 SharePoint team sites from an absorbed regional campus into the university's Microsoft 365 tenant and hand back a clean, decommissioned source environment before the new academic year began. The absorbing institution had 4,200 staff and the regional campus about 900, with both running separate Microsoft 365 tenants for the past six years.
The Challenge: Two Tenants, One Academic Year
Cross-tenant SharePoint migrations are fundamentally different from same-tenant moves. You are not just copying files from one library to another. You are bridging two separate Microsoft 365 identity boundaries, which means:
- User accounts in the source tenant do not automatically map to accounts in the destination tenant without a deliberate mapping exercise
- Permissions assigned to source-tenant users become orphaned on the destination side unless remapped
- Shared links from the source tenant become invalid after migration
- Metadata fields that reference source-tenant users (Created By, Modified By, custom People columns) need to be handled explicitly
- The Microsoft Graph and SharePoint REST APIs operate within a single tenant, so tools that do not support cross-tenant operations will fail silently or incompletely
Coastal University's IT team understood these constraints in theory. What they did not fully appreciate was how quickly those constraints would surface in practice during a live migration attempt.
What They Tried First
Marcus started with the Microsoft SharePoint Migration Tool (SPMT), Microsoft's free on-premises and cloud migration utility. SPMT has a solid track record for same-tenant migrations. For cross-tenant moves, though, its support is limited and the outcome depends heavily on the specific site structure and content types involved.
The first test migration targeted a small team site used by the regional campus's marketing department: 12 GB of files, mostly PDFs and Office documents, with a relatively flat folder structure. The migration completed in just over two hours. On the surface it looked successful. Then the team tried to access the migrated content.
Created By and Modified By metadata had been flattened to a generic service account. Custom columns that referenced people from the source tenant displayed errors. Three document libraries that used content types from the source tenant's content type hub failed to migrate entirely. A Power Automate flow that had been connected to the library stopped working because it had been built against the source tenant's site URL.
The marketing site was a small, simple case. The campus had 43 sites in total, including research collaboration portals, student administration libraries with custom content types, and HR document repositories with per-item unique permissions. If the simplest site had this many issues, a full manual approach was not viable.
When Is the SharePoint Migration Tool Not Enough?
SPMT is the right choice for straightforward same-tenant migrations. It reaches its limits when any of these conditions apply:
- The migration crosses tenant boundaries (source and destination are different Microsoft 365 tenants)
- Sites use custom content types sourced from a tenant-specific content type hub
- Libraries contain items with unique permissions that need to be preserved or remapped
- You need to migrate SharePoint site pages (not just document libraries) with full fidelity
- The source site uses managed metadata term sets that do not exist in the destination tenant
- Your timeline requires concurrent migration of multiple large sites without manual babysitting
- You need a full audit log of what was migrated, what was skipped, and why
Any two or three of these conditions appearing together is enough to make a manual or SPMT-based approach significantly more expensive in staff time than a purpose-built migration tool.
The ShareMaster Approach
Marcus's team evaluated two commercial migration tools. They chose ShareMaster's Clone Master for cross-tenant migration because it did not require a complex server infrastructure or a permanent agent installed in either tenant, and the licensing model was per-migration project rather than per-seat.
Before running any migration, the team used Report Master to export a full permission matrix for each of the 43 sites. The export covered site-level role assignments, library-level unique permissions, item-level unique permissions, and all active sharing links. This took about half a day to run across all sites.
The permission export served three purposes. First, it gave the team a baseline record they could compare against after migration to verify fidelity. Second, it surfaced several sites where permissions were far more tangled than expected, allowing the team to schedule extra time for those sites. Third, it identified 1,200 sharing links across the tenant, many of which were Anyone links with no expiry. The team cleared these before migration to avoid copying stale or risky links to the destination tenant.
Clearing the sharing links used ShareMaster's Shared Links and Permissions tool, which took about two hours across all 43 sites. Doing it manually through the SharePoint admin center would not have been feasible in the time available.
How the Migration Unfolded
The team ran the migration in four waves over eight weeks of the summer break period, prioritising sites by complexity and urgency.
Wave 1 (Weeks 1-2): Low-complexity sites. Twenty sites with flat folder structures, no custom content types, and fewer than 5 GB each. Clone Master migrated these with user mapping applied from a CSV the team had prepared in advance, matching source tenant accounts to destination tenant accounts. Metadata fidelity was preserved, including Created By and Modified By, mapped to the correct destination users.
Wave 2 (Weeks 3-5): Research portals. Eight large sites averaging 40 GB each, with significant file version histories. The team ran Space Master's Version Trimmer on the source sites first, reducing the total data volume by about 30%. This cut migration time per site from an estimated six hours to under four. Clone Master migrated site pages as well as document libraries, preserving the research team's custom navigation and page layouts.
Wave 3 (Weeks 6-7): HR and administration sites. Nine sites with per-item unique permissions and restricted-access subsites. Marcus's team spent extra time on the permission mapping for these sites because errors would have compliance implications. Report Master exports from before and after the migration were compared side by side to verify that every unique permission had been correctly remapped to the destination tenant user.
Wave 4 (Week 8): Remaining six sites plus final verification. The last six sites were small and straightforward. The final week was used for verification: users from the regional campus accessed the destination sites, confirmed they could find their content, and reported back any missing items or permission errors. There were eleven items raised across the whole tenant, all resolved without needing to re-run any migration job.
Outcomes and Lessons Learned
The migration finished with five days to spare before the new academic year. The source tenant was decommissioned on schedule. Marcus's team submitted a post-project report to the university's IT steering committee that included the Report Master permission exports as evidence of pre-migration and post-migration permission states.
Three lessons the team took away from the project:
Start the permission audit before the migration, not during. Running Report Master at the beginning of the project changed the planning conversation. Sites that looked simple on paper turned out to have hundreds of unique permissions. Sites that looked complex were actually cleaner than expected. The audit data drove the wave sequencing and staffing allocation, which meant no surprises during the actual migration runs.
Clean up sharing links before you migrate. Migrating 1,200 stale or risky sharing links to the destination tenant would have immediately created a permission sprawl problem in the new environment. Spending two hours on pre-migration cleanup saved the team from having to run a permissions audit and cleanup exercise after go-live.
Version history adds up. The research sites had accumulated large version histories over six years. Trimming versions before migration with Space Master was faster than migrating and then trimming. It also reduced the risk of hitting Microsoft's migration throttling limits on large sites. If you are planning a similar project, run a version history audit on your source tenant as part of your pre-migration preparation.