How to Plan a Multi‑Geo Tenant Migration in Microsoft 365: A CIO’s Guide - Netwoven

How to Plan a Multi‑Geo Tenant Migration in Microsoft 365: A CIO’s Guide

By Manish Athavale  •  September 26, 2025  •  23 Views

How to Plan a Multi‑Geo Tenant Migration in Microsoft 365: A CIO’s Guide

Introduction

Global organizations walk a tightrope: keep collaboration simple, keep regulators satisfied. Microsoft 365 Multi‑Geo helps you do both by letting you store data at rest in multiple geographic regions while keeping a single tenant and unified admin experience. In practice, that means Exchange Online, OneDrive, SharePoint, and Teams data can live where it must, without fragmenting your environment. 

Let’s level with each other. Multi‑Geo isn’t a toggle you flip on Friday and forget by Monday. It’s a program. It touches licensing, identity, governance, security operations, user experience, and—most importantly—risk. Do it right and you earn agility and trust. Do it poorly and you invite disruption. 

My take (opinion): If you operate across multiple jurisdictions, Multi‑Geo isn’t a “nice to have.” It’s strategic insurance against regulatory and reputational risk. 

What Multi‑Geo Actually Is (and Isn’t)

The architecture in one breath: You keep a Primary Provisioned Geography (your original region) and add Satellite Geographies. All the global “truth” about users, groups, and geo locations is mastered in Microsoft Entra ID, so collaboration remains seamless even as data‑at‑rest is pinned to regional locations. 

Key nuance: Not all workloads behave the same during a Multi‑Geo transition: 

  • Exchange Online mailboxes and Teams chat stores automatically relocate when you change a user’s Preferred Data Location (PDL). New users—if assigned a PDL before licensing—are provisioned directly in the correct geography. 
  • OneDrive sites do not move automatically. They require an admin‑initiated migration. SharePoint sites likewise require planning and configuration.

This distinction is central to your program plan and communications strategy. 

The architecture and governance framework context for Microsoft 365 Multi-Geo (source: Microsoft Learn)
The architecture and governance framework context for Microsoft 365 Multi-Geo (source: Microsoft Learn)

The Licensing Gate: Don’t Trip Here

Microsoft 365 Multi‑Geo is a user‑level add‑on that requires you to license at least 5% of eligible users (you can expand later). Supported plans include Microsoft 365 F1/F3/E3/E5 and corresponding Office 365 plans. The add‑on is needed for each user you host in a satellite region. Cutting corners here is a false economy. 

Opinion: Treat licensing as a readiness gate in your governance process. If a business unit hasn’t funded the add‑ons for its regional employees, they don’t move-simple as that. 

A CIO’s Decision Checklist

  1. Regulatory drivers: Map your data residency obligations by country and workload. If you face multiple regimes (GDPR, sector‑specific regulations), Multi‑Geo gives you levers to comply without splitting the tenant. 
  2. User distribution & collaboration patterns: Where do people work? Who works with whom? These patterns inform your PDL assignments and migration waves. 
  3. Workload scope: Decide where Exchange, Teams, OneDrive, and SharePoint should reside. Remember: Exchange/Teams can auto‑move with PDL; OneDrive/SharePoint need manual action. 
  4. Identity & sync reality: If you synchronize users from on‑premises AD, set PDL as an AD attribute and sync it with Entra Connect; you can’t set PDL directly via Graph for synchronized users. 
  5. Network readiness: Multi‑Geo can improve data residency but doesn’t fix a brittle WAN. Plan for routing and performance as you stretch collaboration globally. 
  6. eDiscovery & compliance boundaries: Align legal hold, eDiscovery, and compliance boundaries to multi‑region storage—then validate. Microsoft provides guidance and references to Purview eDiscovery and boundaries in Multi‑Geo contexts. 

Planning the Program: From Strategy to Runbook

1) Inventory, Classify, Prioritize 

Build a user list with UPN and target PDL codes. Prioritize regulated users and high‑impact teams. Pilot with IT first, then roll to a representative business group. 

2) Governance & Roles 

Decide who owns PDL assignment, who can approve moves, and how exceptions are handled. In Multi‑Geo, some settings become geo‑aware (especially in SharePoint/OneDrive), so define the operating model up front. 

Microsoft Learn diagram highlighting identity, role-based access, and delegation considerations across satellite geographies: (Source Microsoft Learn)
Microsoft Learn diagram highlighting identity, role-based access, and delegation considerations across satellite geographies: (Source Microsoft Learn)

3) Enable the Feature and Configure Workloads

After you purchase the add‑on, Microsoft completes a one‑time tenant configuration. You’ll see workload‑specific notifications when ready. No customer‑driven configuration is needed for Exchange Online or Teams to support Multi‑Geo. For SharePoint/OneDrive, you must add satellite geos in the SharePoint admin center (Geo Locations tab). Provisioning can take a few hours up to 72 hours per geo. 

CIO POV: Treat the 72‑hour window as a planning buffer, not a hard SLA. Align it with your pilot schedule to avoid last‑minute surprises. 

Example architecture showing service enablement and regional configurations in a global Microsoft cloud environment (source: Microsoft Learn)
Example architecture showing service enablement and regional configurations in a global Microsoft cloud environment (source: Microsoft Learn)

4) Map and Set PDL

  • New users: Set PDL before license assignment to provision data in the desired geography. 
  • Existing users: Updating PDL triggers automatic relocation of Exchange mailboxes and Teams chat stores. Track progress and measure user impact. 

5) Plan OneDrive & SharePoint Moves

Since OneDrive and SharePoint don’t auto‑migrate with PDL, define your tooling and sequence. For OneDrive, Microsoft now supports cross‑tenant OneDrive moves (useful in M&A), with strict prerequisites and path length considerations—more on that below. For in‑tenant Multi‑Geo moves, orchestrate OneDrive and SharePoint site migrations after the satellite geos are provisioned and PDLs are set. 

6) User Communications & Support

Communicate early. For mailbox moves, plan downtime windows and FAQs. For OneDrive/SharePoint, explain what moves, what stays, and how sharing and links behave. 

Implementation Details That Save Projects

Exchange Online & Teams: The “Easy Button” 

Once Multi‑Geo is enabled, no extra customer configuration is needed for Exchange Online or Teams. They’ll honor PDL for new provisioning and will relocate existing mailboxes/chats when you change PDL. That doesn’t mean zero effort—monitoring, change control, and communications still matter—but the lift is lighter. 

SharePoint & OneDrive: Where Craft Matters

Enabling Multi‑Geo for SharePoint/OneDrive is a Customer‑driven step. In the SharePoint admin center, the Geo Locations tab appears once the tenancy is enabled. You add each satellite location, assign its domain, and wait for provisioning to complete before switching users. Default settings are applied initially; tune them for local compliance needs afterward. 

Tip (opinion): Keep satellite geo domains short and consistent. It reduces URL sprawl and makes life easier for admins and users alike. 

Timelines & Performance: Set Expectations Like a Pro 

Mailbox moves are subject to service throttling and workload availability, so velocity varies. Still, Microsoft shares helpful P50/P90 estimates for mailbox moves in GoLocal/Multi‑Geo scenarios: 

  • 0–10 GB: ~1 day (P50) 
  • 10–50 GB: ~2–6 days (P50–P90) 
  • 50–100 GB: ~4–11 days (P50–P90) 
  • 100–200 GB: ~6–14 days (P50–P90) 
  • >200 GB: Not supported for this move type. 

These are guidelines, not promises. Your mileage may vary based on load, concurrency, and environmental factors. 

CIO POV: Use the P90 numbers in stakeholder communications. Under‑promise. Over‑deliver. 

Special Case: Cross‑Tenant Moves (M&A, Divestitures)

Your Multi‑Geo program may intersect with tenant‑to‑tenant migrations: mergers, acquisitions, or carve‑outs. Microsoft’s architecture model outlines approaches (single‑event, phased, split) that you can adapt to your scenario. Most enterprises engage Microsoft or a partner here—wisely so.

For cross‑tenant OneDrive, Microsoft provides first‑party tooling with strict prerequisites, license requirements, and scale limits (for example, queue up to 4,000 OneDrive accounts at once). Watch for path length limits (400 characters) and legal hold constraints. Plan identity mapping and trust relationships carefully. 

For cross‑tenant SharePoint, an important fine point: Multi‑Geo customers must treat each geography as a separate tenant—use the correct geo‑specific admin URLs end‑to‑end during migrations. That single sentence has saved many teams from hours of troubleshooting. 

Compliance, eDiscovery & Boundaries

Multi‑Geo is as much a compliance program as it is an IT project. Plan for Microsoft Purview eDiscovery usage across geos and configure compliance boundaries that reflect who can see what, and where. Microsoft’s Multi‑Geo overview ties out to the relevant Purview eDiscovery and boundary guidance—make that mandatory reading for your legal and security teams. 

Opinion: Don’t wait for Day 2 to think about eDiscovery. Bake it into your pilot acceptance criteria. 

Risks & Mitigations (So You Don’t Learn the Hard Way)

  • PDL hygiene: Users without a valid PDL default to the primary geography. Put controls in place to prevent “no‑PDL” users from slipping through. 
  • OneDrive path length & quotas: Long paths (over 400 characters) and extremely large libraries can break migrations. Shorten target OneDrive URLs and rationalize deep folder trees pre‑move. Also respect the 5 TB / 1M item OneDrive thresholds during cross‑tenant moves. 
  • Provisioning time: Satellite geos can take up to 72 hours to provision—align that with project wave planning. 
  • Network performance: Rethink routing and optimize Microsoft 365 connectivity to avoid latency‑induced adoption dips. 
  • Change fatigue: Absent clear communications, even a smooth migration feels bumpy. Over‑communicate pilots, freezes, and cutovers. 

 A Practical Playbook (Phased, Battle‑Tested)

Phase 0 — Strategy & Readiness (2–4 weeks)

  • Confirm regulatory drivers and target geos. 
  • Purchase Multi‑Geo add‑on licenses (≥5% of eligible users to start). 
  • Build the authoritative user‑to‑PDL mapping; align with Entra Connect if you sync from AD.

Phase 1 — Tenant Enablement (1–3 weeks)

  • Microsoft completes tenant enablement post‑purchase; you receive workload‑specific notifications. 
  • In SharePoint admin center, add satellite geos and wait for provisioning (hours to 72 hours). 

Phase 2 — Pilot (2–4 weeks)

  • Pilot with IT and a small business group. 
  • Set PDL before licensing for any net‑new users; update PDL for pilot users to trigger Exchange/Teams moves. 
  • Plan and execute OneDrive/SharePoint pilot migrations; validate user experience and eDiscovery. 
Phase 3 — Scale (4–12+ weeks, wave‑based)
  • Expand by region or business unit. 
  • Monitor mailbox move durations against P50/P90 benchmarks and adjust concurrency. 
  • Track support tickets, latency, and adoption signals

Phase 4 — Stabilize & Optimize (ongoing)

  • Tune compliance boundaries per geo. 
  • Normalize admin processes and runbooks for geo‑aware tasks. 
  • Review PDL accuracy quarterly; new hires and transfers drift fast. 

Budget & Resourcing: What to Expect

  • Licensing: Multi‑Geo add‑on (per‑user in satellite geos; start with ≥5%). 
  • People: Architect (identity + security), M365 admin (EXO/Teams/SPO/OneDrive), network engineer, project/change manager, and legal/compliance stakeholders. 
  • Tools: Native admin centers, PowerShell, possible third‑party tools for advanced migration scenarios; Microsoft’s guidance has pathways for both native and third‑party approaches in email migrations and cross‑tenant scenarios. 

How You’ll Measure Success

  • Compliance coverage: % of in‑scope users correctly hosted in required geos. 
  • Performance & reliability: Mailbox move durations vs. benchmarks; incident rate during cutovers. 
  • User experience: Ticket volume, CSAT, and collaboration quality post‑move. 
  • Operational hygiene: PDL drift rate, eDiscovery request fulfillment time, and backup/restore validation in each geo. 

Frequently Asked (and Important) Questions

Do we need a separate tenant per country?

No. The whole point of Multi‑Geo is to keep a single tenant while placing data at rest in multiple regions.

Do Teams and Exchange require extra configuration?

Not for Multi‑Geo support once enabled. They honor PDL automatically for provisioning and relocation. You still need to monitor and manage change.

How long do mailbox moves take?

Plan in days, not hours. Expect 1–14 days depending on mailbox size and conditions; >200 GB mailboxes aren’t supported for this specific GoLocal/Multi‑Geo move type. Use P90 numbers for executive comms.

What about OneDrive and SharePoint?

They require explicit migration steps. In cross‑tenant scenarios, follow Microsoft’s first‑party guidance and mind path limits, legal holds, and trust relationships. In Multi‑Geo (single tenant), configure satellite geos first, then move content.

Can we move entire tenants between geos?

Microsoft provides a tenant roadmap and guidance on moving tenant geographic locations, plus Multi‑Geo deployment paths for multi‑region needs. For full tenant‑to‑tenant moves (M&A), follow the architecture model and engage experienced partners.

The checklist lays the foundation-this article expands on how to overcome challenges and execute with confidence.

Conclusion

Multi‑Geo is a compliance lever and a collaboration enabler—but only if you treat it like a program, not a project. Put governance first, pilot with purpose, and be ruthless about PDL hygiene. And remember: the goal isn’t just to move data; it’s to earn trust from regulators and employees in every region you serve.

Manish Athavale

Manish Athavale

Manish is a Senior Engagement Manager in the Cloud Infrastructure and Security Practice specializing in Microsoft Purview product suite. He brings extensive experience to Netwoven in Business Analysis, Solution Architecture and Project Management. He has led mid to large sized projects implementing several Microsoft solutions, custom applications and migrations from on-premise SharePoint to Microsoft 365, Jive to Microsoft 365 and Tenant to Tenant migrations. Prior to joining Netwoven, Manish worked a Senior Architect at AEP Inc. responsible to deliver migration of SharePoint on-premise to Microsoft 365 and converting 100s of workflows and forms to Power Platform solutions. Prior to AEP, Manish has worked in several large organizations in Banking, Insurance, Healthcare, Government and Automotive verticals. Manish holds a Master of Science in Mathematics from University of New Orleans and Bachelor of Engineering from College of Engineering, Aurangabad. In his spare time Manish likes to play Tennis, Golf, watch New Orleans Saints football and travel with family.

Leave a comment

Your email address will not be published. Required fields are marked *

Dublin Chamber of Commerce
Microsoft Partner
Microsoft Partner
Microsoft Partner
Microsoft Partner
Microsoft Partner
Microsoft Partner
Microsoft Fast Track
Microsoft Partner
MISA
MISA
Unravel The Complex
Stay Connected

Subscribe and receive the latest insights

Netwoven Inc. - Microsoft Solutions Partner

Get involved by tagging Netwoven experiences using our official hashtag #UnravelTheComplex