Migrating a website between data centers or cloud regions

Moving a site to a different data center or cloud region is a full migration: new servers, a new network, and typically a new IP and DNS answer. The goal is to relocate without losing data and with a cutover that resolves quickly rather than leaving users stuck on stale records.

Choose a region

• Match the region to your audience. A lower round-trip time to your users matters more than a slightly cheaper server. Check the latency (for example with a global health-check service) between candidate regions and where most of your traffic comes from.
• Review region-specific rules. Some data centers and cloud regions apply data-residency or compliance controls (such as storing EU personal data in an EU region). Confirm your data can lawfully live in the region you pick.
• Check feature parity. A codebase that runs in one region may meet quota or service differences in another, so clone the architecture into the target region rather than assuming identical capacity.

Move the data

1. Snapshot the source. Take a full backup of files and database (for WordPress this follows the same pattern as a backup restore drill) so you can fail back if the move goes wrong.
2. Do a full copy first, then an incremental copy. Seed the destination with a complete transfer, then sync only the changes during the cutover window. Tools like rsync for files and a database dump-then-replay for SQL fit this pattern.
3. Re-apply environment-specific values. Update the destination's config file for the new region: hostnames, database endpoints, object-storage buckets, cache URLs and API keys. Configuration lives outside the repo, so port it carefully (see .env portability).
4. Reissue or copy SSL. If the new region issues certificates automatically, let it validate control; otherwise install the private key and certificate on the destination. A certificate you copy is trusted as long as the domain matches, which pairs with the SSL reissue checklist.

Cut over DNS

• Lower TTL the day before. Set the A and AAAA records for the domain (or the relevant subdomains) to a short value such as 300 seconds so cached answers expire quickly.
• Point the records at the new IP. Change the A record (and AAAA, if the region uses IPv6) to the destination address. If you use a load balancer or a CDN hostname, point the CNAME there instead.
• Verify against the new IP directly. Before reliance, confirm regions resolve correctly with a global DNS checker and that no authoritative server still answers with the old IP (a DNS cutover test covers this well).
• Watch for mixed answers during propagation. During the TTL window you will see both old and new addresses. Keep the old server running and serving the copy until traffic fully settles, and only decommission it after a clean confirmation.
• Recheck SSL and mixed content. After cutover, load the page over HTTPS and confirm the padlock is valid and that nothing references the old hostname or an old hard-coded URL.

Prevention

Keep a small runbook: source and destination accounts, the region IDs, the list of movable IP/records, and the rollback path (point DNS back to the old IP and confirm the old server is still running). Test a fail-back once before the real move so a rollback is not a first-time operation.

When to involve a professional

Involve your cloud provider or a migration specialist if the site spans many interconnected services (databases, queues, object storage, auto-scaling) or if you need zero-downtime cutover, because this is materially more complex than copying static files.