operations 10 min read Updated June 16, 2026

Migrating between jurisdictions

Answer

Migrate between jurisdictions by provisioning the target first, syncing data with rsync or a database replica, lowering DNS TTL 48 hours ahead, cutting over during low traffic, and verifying before destroying the source. Expect minutes of downtime, not hours.

Lower the TTL first, and do it early

Forty-eight hours before the move, drop your DNS records to a 300-second TTL. Resolvers cache aggressively and a record still carrying a 24-hour TTL will keep sending traffic to the old address long after you have finished.

This is the step people skip and then regret. It costs nothing and it converts a day of stragglers into five minutes.

Sync in two passes

Do a full rsync while the source is still live and serving. It takes as long as it takes and nothing is disrupted. Then stop the application, run a second rsync that transfers only what changed since the first, and cut over. The second pass is usually seconds.

For databases, use replication rather than file copy: set the new server up as a replica, let it catch up, then promote it. Copying database files from a running server produces a corrupt copy often enough that it is not worth the risk.

T-48h — DNS TTL to 300 seconds
T-2h — full rsync, source still live
T-30m — database replica caught up
T-0 — stop app, final rsync, promote replica
T+5m — DNS updated, verify from several networks
T+72h — verify, then destroy the source

What to check before you destroy anything

Wait at least seventy-two hours. Watch the old server’s logs for traffic still arriving — that tells you which resolvers or hard-coded clients have not moved. Verify your backups restore from the new location, not just that they run.

Check anything that referenced the old IP address directly: firewall allowlists on third-party services, API allowlists, monitoring checks, and any DNS record you forgot about. There is always one.

The part specific to jurisdiction changes

If the reason for the move is legal rather than technical, the old disk matters. Ask us to wipe it rather than simply terminating the server — we run a multi-pass overwrite on request and confirm when it is done. On an encrypted volume, destroying the LUKS header is faster and equally effective.

Also re-check anything that hard-codes a country: TLS certificates are fine, but geo-restricted third-party APIs, payment integrations and compliance attestations may not be. It is better to find that out before the cutover than after.

FAQ

Frequently asked questions

01 How much downtime should I expect?

Minutes, if you lower the TTL 48 hours ahead and sync in two passes. The final rsync on a pre-synced dataset is usually seconds; DNS propagation at a 300-second TTL is five minutes.

02 Can you migrate the server for me?

We can move disk images between our own locations on request, which avoids re-syncing entirely. Application-level cutover is still yours, because only you know when it is safe.

03 What happens to the old disk?

Terminated volumes are wiped on reallocation as standard. If the move is legally motivated, ask for a multi-pass overwrite and we confirm when it completes. On LUKS volumes, destroying the header is faster and just as final.

GuideChoosing an offshore jurisdictionChoose a jurisdiction by working backwards from your adversary.Use caseBackup hostingOffsite backup hosting gives you a remote target for encrypted backups, in a different jurisdiction from your primary infrastructure.TopicOffshore hostingOffshore hosting places your server in a jurisdiction chosen for its legal properties rather than its latency.GuideVPS vs dedicated serverChoose a VPS until you need predictable tail latency, more than 64 GB of RAM, or hardware-level control.