Migrating Personal Data Between Cloud Regions Without Breaking Cross-Border Rules

Section 16 restricts transfer of personal data to specific countries or territories the government notifies as restricted, which is structurally different from an adequacy allowlist model where you check a destination against a fixed approved list. It means there is no static list you can hardcode into a migration plan and consider settled; the compliance-relevant fact is whether a destination is currently notified as restricted, which can change, and your migration process needs a way to check that at the time of migration rather than relying on an assumption formed when the project started.

For most cloud region migrations this is less dramatic in practice than it sounds, since major cloud provider regions are typically not obscure or high-risk destinations, but the discipline of actually checking rather than assuming matters, especially for migrations to newer or less common regions, or for any migration involving a processor outside the primary cloud relationship.

A region migration for personal data is rarely a clean cutover; the common pattern is dual-write, where new writes go to both the old and new region during a transition window, backed by a backfill process that copies historical data across, followed by a read cutover once backfill is verified complete and consistent. This pattern needs the same personal-data-aware handling in both directions — encryption, access controls, and audit logging need to be equivalent in the new region before any read traffic moves, not retrofitted afterward.

The backfill process itself is a bulk data movement operation touching every record, which makes it a natural point to also verify data quality and catch any records that should have already been erased but were not, if your erasure pipeline had gaps. Treat the migration as an opportunity to reconcile against the erasure log, not just a lift-and-shift of whatever is currently in the source region.

A consent withdrawal or erasure request that arrives mid-migration is a genuine edge case worth planning for explicitly, since during the dual-write window a record might exist in both regions simultaneously and an erasure needs to hit both, not just whichever region currently handles reads. Route erasure and correction operations to both regions during the transition window rather than only the region currently considered authoritative, and only stop dual-processing these requests once cutover is fully complete and the old region's data is being decommissioned.

Access requests during migration have a similar consideration: if you are compiling a data export for a Data Principal mid-migration, make sure the compilation process checks both regions rather than only the new one, since a partial backfill could mean some historical records are still only present in the source region at the moment the request is processed.

Once cutover is complete and the new region is authoritative, the source region's data needs to actually be deleted, not just left dormant because decommissioning felt like a lower priority than the migration itself. A dormant old-region copy of personal data is a real exposure and a real erasure-rights gap if anyone ever requested erasure of data that then continues sitting untouched in a deprovisioned but not actually deleted source environment.

Build source-region deletion into the migration project plan as a tracked, verified step with a completion date, not an informal cleanup task that happens whenever someone gets around to it. Confirm deletion at the storage layer, not just at the application layer, since orphaned backups or snapshots in the source region can outlive the primary dataset's deletion by a wide margin if nobody checks.

The Data Flow Mapper tool on this site is useful for tracking exactly which systems and regions hold which categories of personal data before, during, and after a migration like this, so nothing gets left behind in the source region unnoticed.