Organizations usually arrive at data localization through a document: a regulation, a customer contract, an internal policy. The document says certain data must stay within a jurisdiction. What it never says is where that data is today.
The inventory is the hard part
In every assessment we run, the same surprise appears. The primary database is well understood and already in the right place. The leaks are everywhere else: log shipping to a service in another region, error tracking that captures request payloads, a document-generation API, nightly exports into a warehouse, and backups replicated to wherever the default was.
Until that map exists, any infrastructure decision is guesswork. We would rather spend two weeks tracing flows than move a platform and discover the obligation was never satisfied.
Classify, then place
The second mistake is applying the strictest rule to everything. Residency obligations usually attach to specific categories — personal data, health records, transaction detail. Marketing content and public documentation rarely carry the same constraint. Separating them lets you spend control where it matters and keep the rest simple.
Design the exceptions deliberately
Some dependencies are genuinely hard to remove. The answer is not to pretend they do not exist, but to record what data reaches them, why, and what happens if that route has to close. An exception you have written down is a managed risk; one you have not is a finding waiting to be made.
Then choose infrastructure
Only at this point does the platform decision become concrete: which workloads must run locally, what they depend on, and what the recovery story is. That is an engineering conversation, and it goes quickly once the first three steps are done.