Lessons learned from large tenant‑to‑tenant migrations

Lessons learned from large tenant‑to‑tenant migrations

Large tenant‑to‑tenant (T2T) migrations are complex, multi‑workload programmes that touch every layer of Microsoft 365. Over time, recurring patterns and lessons emerge, especially when dealing with thousands of users, legacy configurations, holds, storage constraints, and identity dependencies. Below are some of the most valuable lessons we’ve learned from delivering large‑scale M365 migrations.

Lesson 1: Active Users vs Leavers: The hidden challenge of holds

Migrating active users is typically straightforward. However, leaver accounts often introduce unexpected delays, particularly when they are under:

  • eDiscovery hold
  • Litigation hold
  • Retention hold
  • In‑place holds
  • Legacy preservation policies

These controls prevent normal removal or restoration processes. To migrate a mailbox or OneDrive, the account must first be restored, which is a task that can be time‑consuming when large numbers of leaver accounts are held for compliance reasons.

Takeaway

Restore all leaver mailboxes and OneDrives early, long before any migration waves begin. Doing this early allows time to:

  • Validate each restored object in the migration tool
  • Resolve policy or retention issues
  • Extract correct UPN and SMTP values
  • Avoid last‑minute blockers that impact cutover

Proactive restoration is essential for clean identity mapping and tool readiness.

Lesson 2: Large shared or unlicensed mailboxes: size & licensing limitations

Larger mailboxes frequently cause issues, particularly if previously active user mailboxes have been converted to shared. While shared mailboxes can be created without a licence, they are limited to:

  • 50 GB primary mailbox
  • 50 GB archive mailbox

They also do not support auto‑expanding archiving unless licensed.

When source mailboxes exceed these limits, target provisioning becomes more complex.

Takeaway

Provision target mailboxes early, and assign licences where the source mailbox exceeds the 50 GB shared mailbox limit. This can prevent situations where:

  • Migration tools cannot write data because the target mailbox is undersized
  • Archive content >50 GB cannot be migrated without a licence
  • Migrations fail because the mailbox was not created or licensed in advance

For leaver OneDrives, data often must be migrated into classic SharePoint team sites using consistent naming, such as:

https://neroblancoit.sharepoint.com/sites/LVR_ISokolaj

Provisioning these sites early ensures URL stability and correct identity mapping.

Lesson 3: Maintaining the Master Migration List (MML)

The Master Migration List is the authoritative source for identity mapping. However, with multiple teams updating it over months, inconsistencies or formatting drift can easily occur.

Takeaway

Review and validate the MML regularly, and never alter its structure. Key practices for this include:

  • Strict version control
  • Mandatory population of required fields
  • Consistent formatting and column order
  • A single owner accountable for data quality

A clean MML prevents mismatches, provisioning issues, and mapping failures.

Lesson 4: Storage constraints – one of the biggest risks

Large migrations often push SharePoint and OneDrive storage to their limits. A real risk is running out of space mid‑project, which can halt migrations entirely.

Takeaway

Monitor storage from day one and secure additional capacity early.

Side note: Additional storage can take weeks to provision, so forecasting usage and planning ahead is essential.

So to conclude: successful tenant‑to‑tenant migrations depend on early restoration of leavers, careful licensing and provisioning of large mailboxes, strict MML governance, and proactive storage management. Applying these lessons ensures smoother execution, fewer surprises, and a far more predictable migration journey.