Data Residency Email Migration: Crossing Borders Safely

Data residency turns an email migration from a technical project into a legal one. The mechanics of IMAP and Exchange Web Services do not care whether mailbox bytes leave the EU, but your DPO does, and so does your auditor, and so do the courts that decided Schrems II. This post walks you through what residency actually means for Microsoft 365 and Google Workspace migrations, how the EU Data Boundary and Workspace data regions work in practice, and why the architecture of your migration tool matters as much as your choice of destination.

What "data residency" actually means#

Data residency is the principle that data subject to a particular jurisdiction stays inside that jurisdiction at rest. It overlaps with two related ideas:

• Data sovereignty: the data is subject to the laws of the country it is stored in, including law enforcement access requirements.
• Data localisation: a stronger version where data must be processed inside the country too, not just stored there.

For email migrations, the practical questions are simple:

1. Where does the source mailbox live, physically?
2. Where will the destination mailbox live, physically?
3. What happens to the bytes in between?

A migration that stays inside one region is operationally easier and legally simpler. A migration that crosses regions is doable, but the path matters. The bytes in transit need a legal basis, and any intermediate storage adds another residency consideration on top of the source and destination ones.

If you have not yet read the broader email migration compliance guide, it is worth doing so first. It covers the controls scaffolding around residency, GDPR, HIPAA, and SOC 2 in one place.

The EU Data Boundary in Microsoft 365#

Microsoft has spent the last several years building the EU Data Boundary for the Cloud, which keeps customer data for in-scope services inside EU and EFTA member states at rest and for the majority of processing. For Exchange Online and the rest of Microsoft 365, this means EU-tenanted customer data sits in EU datacentres and is processed by EU-located services for ordinary mail flow, search, and indexing.

What this means for a migration:

• A tenant provisioned in the EU geo has its mailboxes stored in EU datacentres by default.
• Cross-tenant migrations between two EU-geo tenants do not need to leave the boundary if the tooling cooperates.
• Cross-tenant migrations between an EU geo tenant and one in another geo (Americas, APAC) involve a cross-border transfer regardless of tooling.

The EU Data Boundary is not absolute. Microsoft documents a limited set of transfers that still happen, mostly for security operations, abuse investigations, and a narrow class of professional services and remote support sessions. For a routine migration, those exceptions do not apply, but check your DPA and your tenant's geo if you have a specific concern.

How to confirm your tenant geo#

Your tenant's primary geo is set at creation and is generally not changeable without Microsoft assistance. You can confirm it in the Microsoft 365 admin center under organization settings, or by checking the location of mailboxes via PowerShell. If a tenant is multi-geo, individual mailboxes can be placed in specific satellite geos, but the primary geo still determines a lot of metadata storage.

For a migration project, write down the geo of both tenants at the start. If they match, your residency story is short. If they do not, you need to think about transfer mechanism, the GDPR email migration implications, and whether end users need to know.

Google Workspace data regions#

Workspace's equivalent is data regions, which let admins choose where covered data is stored at rest: United States, Europe, or "no preference" (anywhere). On eligible editions (Enterprise, Education Plus, and some others), you set the region at the organizational unit level. Workspace then migrates the existing covered data into the chosen region's datacentres.

A few practical notes:

• Data region applies to covered data at rest (Gmail message bodies, Drive files, Calendar entries, and several others). It does not cover ephemeral processing, some backup tiers, or transit between Google's own services.
• A change of data region is a Google-managed move. It can take days or weeks for large organisations. It is not a migration in the IMAP sense; you do not run a tool.
• For mailboxes leaving Google Workspace entirely, the data region setting is irrelevant once the export starts. The bytes leave Workspace through whatever path your migration tool uses.

If you are moving from Workspace to Microsoft 365 and care about residency, the destination tenant's geo matters far more than where Workspace was storing the source data. The transit path is the third variable.

Schrems II and what it changed#

Schrems II, the 2020 ruling by the Court of Justice of the European Union, invalidated the EU-US Privacy Shield as a basis for transferring personal data from the EU to the US. It also tightened expectations around the use of Standard Contractual Clauses (SCCs), the alternative legal mechanism. SCCs are still valid, but data exporters have to do a Transfer Impact Assessment (TIA) and may need supplementary measures (technical, contractual, or organisational) to protect data against US government access.

The EU-US Data Privacy Framework (DPF) replaced the Privacy Shield in 2023 and provides a renewed adequacy basis for certified US recipients. It is itself under legal challenge, so treat the legal landscape as live rather than settled.

What this means for an email migration:

• A transfer of EU personal data to a US-based migration tool's relay servers is an international transfer. It needs a legal basis (DPF, SCCs, or another mechanism) and possibly a TIA.
• A transfer of EU personal data through a tool that runs locally on an EU-located admin workstation, with mail flowing directly between EU-located source and destination tenants, is not an international transfer at all. The bytes never leave the EU.

The legal complexity does not go away if the destination tenant is non-EU. It does, however, change what you are documenting and which mechanisms you rely on.

Why a local-first migration tool simplifies residency#

Migration tools generally fall into two architectures:

1. Cloud-hosted: you sign in to a SaaS, give it OAuth grants to source and destination, and it pulls mail through its own infrastructure. Mailbox bytes pass through the vendor's region(s).
2. Local-first / desktop: you install a client on a workstation, the client signs in to source and destination, and mail moves directly between them via the workstation. No vendor infrastructure touches the bytes.

For residency, the local-first model has structural advantages:

• The transfer path is one you already document and control.
• You do not add a new vendor to your data flow diagrams.
• The location of mailbox processing is the location of the workstation, which you choose.
• There is no shared multi-tenant environment to assess for confidentiality.

That last point matters for confidentiality and SOC 2 too. The companion post on SOC 2 email migration covers the control overlap.

This is the architecture Mailbox Taxi uses by design. The bytes flow from source IMAP, through the IMAP client on your workstation, into destination IMAP. If your workstation is in Frankfurt, the bytes are in Frankfurt while you process them. If you run the migration overnight from an EU office, the EU is where the work happens. Residency follows the workstation.

Multi-region tenants and satellite geographies#

Both Microsoft 365 and Google Workspace support multi-region setups. Microsoft Multi-Geo lets you provision satellite locations within a tenant; mailboxes are then placed in specific geos. Workspace's data regions can be configured per organizational unit.

If you are migrating into a multi-geo tenant, the destination geo of each mailbox depends on the user's geo assignment, not just the tenant's primary geo. The migration tool needs to respect this, which usually means waiting for the user to be provisioned with the right region attribute before the mailbox itself is created and populated.

For multi-geo migrations, the tenant-to-tenant migration playbook covers the operational pattern: pre-provision users with their target geo attributes, let provisioning complete, then run mailbox content migration. Doing it in the wrong order means mailboxes land in the primary geo and have to be moved later by a tenant-internal process.

What documentation you need before you start#

Before the first batch runs, your residency paperwork should include:

• Source tenant geo with screenshot or PowerShell output.
• Destination tenant geo the same way.
• Migration workstation location (which office, which country).
• Transfer mechanism if crossing borders: DPF certification, SCCs, BCRs, or an applicable derogation.
• Transfer Impact Assessment if SCCs are your mechanism.
• Data Processing Addendum with the migration tool vendor if the vendor processes personal data.
• Records of Processing Activities (ROPA) entry for the migration as a processing activity.

Most of this is light if you stay within one region. The ROPA entry is usually a paragraph. The TIA is the heaviest piece and only applies if you are leaning on SCCs.

Sector-specific residency rules#

Beyond GDPR's general framework, several sectors and jurisdictions have specific residency requirements that may affect an email migration:

• Financial services in the EU: outsourcing rules (EBA guidelines, DORA) impose obligations on critical cloud providers and may require notification of migrations.
• Healthcare: HIPAA in the US does not require US-only storage, but state laws and BAAs may. EU healthcare regulations and national rules often do.
• Public sector: many EU member states require public bodies to use sovereign cloud offerings, which restricts both tenant location and migration tool choice.
• Russia, China, Saudi Arabia, and others: domestic data localisation laws often require local storage and processing for certain data types about local residents.

These rules layer on top of the general data residency framework rather than replacing it. They usually narrow your options for tenant geo and migration architecture, sometimes to the point where only on-premises or sovereign cloud options qualify.

Operational pattern for a residency-safe migration#

Putting it together, here is a workable pattern for a migration that respects residency:

1. Confirm geos for source tenant, destination tenant, admin workstation, and any storage the migration tool uses.
2. Pick a tool whose data path matches your residency story. A local-first tool that processes on the workstation needs no additional residency analysis if the workstation is in the right region.
3. Document the data flow as a one-page diagram showing source, destination, workstation, and any intermediate storage. Attach it to the change ticket.
4. Use a workstation physically in the correct region, not just an admin's laptop that happens to be wherever they are travelling that week.
5. Restrict network egress on the workstation to the source and destination IMAP/HTTPS endpoints during the migration window. This protects against the tool reaching out to vendor cloud services you did not anticipate.
6. Log everything in a way that proves where processing happened. The email migration audit log post covers what to capture and how to keep it.
7. Validate residency post-migration: confirm destination mailboxes are in the expected geo. For Microsoft 365 this is a PowerShell call; for Workspace, an admin console check.

When residency forces architectural choices#

Sometimes residency rules out the migration approach you wanted. Three patterns come up:

• The "we cannot use a cloud migration tool" case. Some EU public sector buyers, some healthcare providers, and most defence-adjacent organisations will not approve a US-domiciled SaaS migration tool. Local-first or on-prem tools are the only options.
• The "we have to migrate in two stages" case. You sometimes cannot move EU mailboxes directly to a non-EU destination because the destination has not yet been region-configured. The fix is to provision the destination region first (multi-geo, Workspace data regions), wait for the move to settle, then run the mailbox migration into the correct region.
• The "we cannot move at all" case. Occasionally a regulator restriction or a contract clause means specific mailboxes cannot leave their current jurisdiction. Identify these before scoping the project; they need their own residency strategy.

If you are running an Office 365 destination, the Office 365 migration guide covers the geo and provisioning details for the destination side. The complete email migration guide covers the project structure that wraps around it.

Two short scenarios#

Scenario one: EU-to-EU, same provider. A 400-user organisation moves from one EU-geo Microsoft 365 tenant to another following an acquisition. Both tenants are in the EU geo. The MSP runs the migration from a workstation in Dublin. Mail bytes never leave the EU. Residency paperwork is two paragraphs in the change ticket plus the data flow diagram.

Scenario two: US-to-EU, cross-provider. A growing SaaS company moves from a US Workspace tenant to a new EU-geo Microsoft 365 tenant after opening a European HQ. The destination is EU. The source is US. The data flow has an unavoidable cross-border element. The team runs the migration from an Amsterdam-based admin workstation. The transfer mechanism is the EU-US Data Privacy Framework, with SCCs as a backup, and a TIA documented. The migration tool is local-first, so the bytes pass through the workstation only, not a third-party cloud. All of this gets documented in a longer change ticket with the legal team copied in.

Both scenarios are workable. The second one takes more upfront paperwork but is not harder operationally.