Your input shapes our product. Suggest a feature now →
  1. Home
  2. Use Cases
  3. Cross-Tenant Merger Migration

Cross-Tenant SharePoint Migration After a Company Acquisition

Meet David Chen. He runs a small IT consultancy that specialises in Microsoft 365 migrations. Over the past four years, David has managed everything from straightforward on-premises to cloud lifts to complex multi-site tenant consolidations. Post-acquisition migrations are his most frequent engagement type, and they are consistently the ones that carry the most business pressure. The client's leadership wants the two companies operating on a single platform as quickly as possible. IT needs to make that happen without losing data or disrupting the teams who depend on it.

Role: Independent IT migration consultant

Client: Northfield Group (150 staff), which acquired Meridian Partners (90 staff) in early 2026

Challenge: Migrate all Meridian SharePoint Online and OneDrive content into the Northfield Microsoft 365 tenant within six weeks of the deal closing

Scope: 14 SharePoint Online sites, 180 GB of files and list data, OneDrive for 90 users

The brief

Northfield Group acquired Meridian Partners to expand its professional services practice. Both companies were already on Microsoft 365, each with their own separate tenant. There was no existing trust relationship between the tenants: no Azure AD federation, no cross-tenant sync, no shared admin credentials. From a technical standpoint, each tenant was completely isolated from the other.

Northfield's IT manager engaged David two weeks after the deal closed. The requirements were clear on the surface: move all of Meridian's SharePoint Online content into Northfield's tenant, move the OneDrive content for each of Meridian's 90 users into their new Northfield accounts, and do it without losing files or corrupting metadata. Northfield's leadership wanted the migration complete before the 90-day integration review scheduled with their board.

Beneath the surface, the project had the usual complications. Several of Meridian's libraries used custom content types and columns that did not exist in Northfield's environment. One department had a filing structure with 12 levels of nested folders that had accumulated over eight years. Three of the sites contained active project work that teams were using daily, meaning the cutover window for those sites had to be tightly planned and communicated.

Assessment and planning

David's first step was a content inventory. Before committing to a migration plan, he needed to understand the scope in detail: how many sites, how many libraries per site, approximate file counts, total storage, and which libraries contained content types that would need mapping.

He used ShareMaster's Explore Master to inspect the hidden properties and content types across Meridian's sites. The inventory revealed that nine of the 14 sites used only standard SharePoint content types, which would migrate cleanly. Five sites used custom content types that would need to be pre-created in Northfield's environment before the migration could run. Two of those five sites were also using custom site columns not present in Northfield's tenant.

With the inventory complete, David structured the migration in two phases. Phase one covered the nine sites with standard content: these could be migrated first, validated, and handed back to users before the more complex sites were touched. Phase two covered the five custom-content sites, with a preparation step to establish the required content types in the destination tenant before any content moved.

Planning principle: separating standard content from custom content early is one of the most reliable ways to reduce migration risk. It means phase one is low-risk and delivers visible progress quickly, while the team is still solving the harder problems in phase two.

Setting up the destination environment

David created the 14 destination site collections in Northfield's tenant before starting any content transfer. He replicated Meridian's site structure and naming convention within a dedicated section of Northfield's tenant to keep the migrated content organised and easy to find during the transition period. He also pre-created the custom content types and site columns identified during the inventory so that the migration would find a matching schema on the destination side.

For the 90 OneDrive accounts, he worked with Northfield's IT manager to confirm that all 90 Meridian users had been provisioned with accounts in the Northfield tenant. Meridian users needed their Microsoft 365 accounts in the destination tenant before their OneDrive content could be migrated into the correct personal store.

Mapping source users to destination accounts was one of the more time-consuming parts of the pre-migration work. Several Meridian staff had changed names between the two tenants (a few had married, one had a preferred name change), and the email address formats differed between the companies. David built a mapping file that paired each Meridian account with its Northfield equivalent to ensure content landed in the right destination.

Running the migration with Clone Master

With the destination environment prepared and the mapping file ready, David used Clone Master to execute the actual content transfer. Clone Master handled the cross-tenant authentication for both the Meridian source and the Northfield destination, running from David's Windows workstation without requiring any persistent federation or trust configuration between the two tenants.

Phase one: standard content sites

David ran the nine standard-content sites over a Thursday night and Friday morning window. He chose a low-activity period to reduce the chance of users modifying files mid-migration, and communicated the schedule to Meridian's team in advance so they knew to save and close any open files before close of business Thursday.

Clone Master migrated sites, libraries, lists, and files. The deep folder structure on the filing-heavy department site migrated without truncation, which had been David's main concern about that particular site. File metadata migrated intact.

After the migration completed, David ran a validation pass on each site: file counts, library structure, and spot checks on individual documents. All nine sites came back clean. Northfield's team confirmed access on Friday morning and the sites were marked ready for handover.

Phase two: custom content sites

The five custom content sites required a more careful run. David had pre-created the content types and columns in Northfield's tenant during the setup phase. He migrated one of the five sites as a test, then reviewed the results before proceeding with the remaining four.

The test site came back with the custom content types intact and the column values preserved. David ran the remaining four sites over the following weekend and completed validation on the Monday morning.

OneDrive migration

With the SharePoint sites complete, David moved to the OneDrive phase. The 90 personal drives ranged from nearly empty to several gigabytes of files. Clone Master handled the OneDrive content using the same cross-tenant approach, mapping each source drive to the corresponding destination account using the user mapping file David had prepared.

A small number of users had files that were still syncing when the migration ran, which created some minor conflicts in those accounts. David identified these from the migration log and handled them individually, which took less than a morning to resolve.

Cutover and handover

The two active project sites that teams were using daily were the last to cut over. David coordinated with the project leads at both teams to pick a Friday evening window. He ran the migration, which by that point was a familiar process with no surprises. Both project sites were live in Northfield's tenant by Saturday morning. Team leads confirmed access and validated their most recent files on Saturday, and confirmed readiness for the working week on Monday.

Northfield's IT manager sent the all-clear to both companies on Sunday evening. The Meridian tenant remained in read-only mode for two weeks after the migration to allow any users who could not find content in the new environment to retrieve it, then it was decommissioned.

Outcome

The full migration completed inside the six-week window. All 14 sites landed in Northfield's tenant with their file structure and metadata intact. The 90 OneDrive accounts were migrated with no reported data loss. The two active project sites had a single weekend cutover window, which teams absorbed without significant disruption.

David's post-migration notes for the client included a recommendation to run a permissions audit on the migrated sites before decommissioning Meridian's tenant, to ensure that any unique permissions or shared links from the Meridian environment had been reviewed and were intentionally carried over rather than migrated by default. He used ShareMaster's Shared Links and Permissions tool to produce a report for that review.

What made this migration work

Post-acquisition migrations go wrong in predictable ways: content inventory is incomplete, the destination is not set up before migration starts, or the cutover plan does not account for active users. David's approach addressed each of these directly: a detailed pre-migration inventory, full destination setup before any content moved, and a phased plan that kept active-use sites to the last window.

For anyone facing a similar cross-tenant migration, the considerations that matter most are:

  • Inventory first. You need to know the scope in detail before you can commit to a timeline. Unknown custom content types discovered mid-migration are a common source of delays.
  • Prepare the destination before you start. Sites, content types, user accounts, and permission groups should exist in the destination tenant before any content transfer begins.
  • Build a user mapping file. Name and email format differences between tenants are more common than expected, especially after a merger. A mapping file prevents content from landing in the wrong account.
  • Phase by risk level. Standard content first, custom content second, actively used content last. This delivers early wins while preserving time to solve harder problems.
  • Plan for a post-migration permissions review. Migrated content carries its source permissions. Those permissions should be reviewed before the source tenant is retired.

Related resources

Try ShareMaster free for 14 days