Migrating a website or server between data centres is safest when treated as a controlled deployment rather than a one-time move. This runbook covers discovery, backups, staging, synchronisation, DNS planning, firewall rules, cutover sequencing, rollback criteria, and the recurring checks that help keep the migration safe as infrastructure changes.
Overview
A data centre migration can involve moving a website, database, virtual machine, dedicated server, or an entire service stack to a new provider or facility. The technical steps vary, but the operating principles are consistent: understand the current system, build and test the destination, reduce the amount of data changed during cutover, and define in advance what will trigger a rollback.
Minimal downtime does not mean that every migration can be completed without interruption. It means designing the move so that any interruption is brief, observable, and reversible. The achievable result depends on the application, database workload, DNS behaviour, storage volume, network connectivity, and whether the destination can run in parallel with the existing environment.
Before choosing a destination, record the requirements that matter to the workload. These may include server capacity, storage performance, network paths, IPv4 or IPv6 support, backup handling, data residency, compliance requirements, DDoS protection, remote hands, and the provider's hosting uptime SLA. A data centre location comparison can also help identify likely latency and operational constraints. For broader infrastructure choices, see VPS vs Dedicated Server vs Bare Metal vs Cloud.
Keep a written migration record containing the owner, change window, dependencies, access details, current and new IP addresses, DNS records, backup locations, test results, contacts, and rollback decision-maker. This document should be usable by someone who did not perform the original discovery.
What to track
1. Inventory and dependencies
Start with an inventory of every component that must move or be updated:
- Web servers, application services, scheduled jobs, queues, workers, and monitoring agents.
- Databases, object storage, file shares, uploaded media, and application-generated files.
- DNS zones, subdomains, mail records, certificates, API endpoints, and third-party integrations.
- Firewall rules, load balancers, allowlists, VPNs, SSH keys, service accounts, and secrets.
- External dependencies such as payment gateways, email services, identity providers, webhooks, and licensing systems.
Record current CPU, memory, storage, disk latency where available, network throughput, request rates, error rates, and backup duration. These figures provide a baseline for deciding whether the destination is behaving normally after the move.
2. Backups and recovery evidence
Do not treat a successful backup job as proof that recovery will work. Create a current backup before migration, verify that it can be read, and test restoration of representative files and databases. Confirm retention, encryption, access permissions, and the location of at least one recovery copy. Document the maximum acceptable data loss and service interruption for the workload.
For a database, check whether the backup is application-consistent and whether transaction logs or binlogs are available for point-in-time recovery. For a website, include configuration files, uploaded content, application code, certificates, scheduled tasks, and the database rather than copying only the document root.
3. Staging and synchronisation
Build the destination before changing public traffic. Match operating system settings, runtime versions, web server configuration, file ownership, time synchronisation, storage mounts, and security controls as closely as practical. Apply updates and remove unnecessary services before exposing the system.
Perform an initial bulk copy, then use an incremental synchronisation method to transfer changes made while the old system remains live. For databases, choose a method appropriate to the engine and workload, such as replication, a restored backup followed by log replay, or a controlled export and import. Avoid assuming that a file copy alone keeps a changing database consistent.
4. DNS and certificate readiness
List every DNS record that may need to change, including the main domain, www host, API names, mail records, verification records, and monitoring endpoints. Lower the relevant DNS time to live before the migration if the existing provider permits it, but do not assume that all resolvers will switch at the same moment.
Install and validate TLS certificates at the destination before cutover. Test redirects, canonical hostnames, HTTP to HTTPS handling, HTTP/2 or HTTP/3 settings where used, and certificate renewal. DNS is only one part of a cutover plan; cached responses mean that old and new systems may receive traffic concurrently.
5. Firewall and access controls
Recreate firewall rules deliberately rather than copying broad temporary access. Permit required application traffic, administration paths, monitoring sources, database connections, backup services, and provider management tools. Restrict database exposure to approved networks and confirm that outbound access required by the application is available.
Test administrative access using more than one approved route before disabling the old server. Keep emergency console or remote hands procedures documented for dedicated servers and colocation deployments. The data centre due diligence checklist provides a useful companion for reviewing facility, connectivity, and recovery considerations.
Cadence and checkpoints
Website migration workflow
- Clone the application and content to the new environment.
- Use a temporary hostname or hosts-file entry to test without changing public DNS.
- Check login, forms, search, uploads, checkout or other critical journeys, redirects, robots directives, and analytics.
- Run a final content synchronisation and place the application in maintenance or read-only mode only if required.
- Change DNS or the load-balancer target, then keep the old site available while traffic transitions.
Database migration workflow
- Measure database size, write rate, replication lag if applicable, and restore time.
- Take and verify a baseline backup.
- Synchronise the destination and monitor lag or outstanding changes.
- At cutover, pause writes or stop application traffic when consistency requires it.
- Apply final changes, validate row counts and key queries, then direct the application to the new database.
VPS migration workflow
For a VPS, decide whether to migrate at the application level, restore an image, or use a provider-supported transfer. Confirm that the new platform supports the required kernel features, networking model, block storage, snapshots, and boot configuration. Test SSH, scheduled jobs, backups, monitoring, and outbound mail before changing the IP address or DNS.
Dedicated server migration workflow
For dedicated server hosting, account for hardware differences, RAID or storage layout, firmware, remote management, rack connectivity, and physical access. Keep a complete configuration export and a recovery plan that does not rely on the old machine remaining available indefinitely. If the server is in colocation, confirm cross-connects, carrier changes, remote hands coverage, and access procedures before the change window.
Use checkpoints rather than relying on elapsed time. A practical sequence is: destination provisioned; baseline backup verified; application test passed; firewall test passed; synchronisation current; final backup completed; DNS or routing change approved; smoke tests passed; monitoring stable; rollback window closed.
How to interpret changes
Compare the destination with the baseline, not with an idealised target. A small difference in response time may be expected if the server region or network path has changed, but a sustained increase in latency, error rate, CPU wait, disk latency, or database connections deserves investigation.
Separate application defects from infrastructure problems. A sudden rise in 5xx responses after cutover may indicate a missing environment variable, blocked dependency, incorrect file permissions, or an incompatible runtime rather than a data centre network fault. Failed health checks from only one region may indicate DNS propagation, routing, or monitoring-path issues. Check several networks and regions before drawing a conclusion.
Define rollback criteria before the migration begins. Examples include unreconciled data, failed critical user journeys, inaccessible administration, inability to restore a backup, sustained application errors above the agreed threshold, or a security control that cannot be reproduced. Rollback may mean restoring the old DNS target, reverting a load-balancer rule, or directing the application back to the original database. Do not roll back blindly if both environments have accepted writes; first establish which data is authoritative.
Keep both systems under observation for a defined period after cutover. Track DNS resolution, traffic distribution, status codes, database health, queue depth, backups, certificates, logs, and user-facing transactions. Review cost and capacity signals as well, since a migration can expose an undersized destination or unused resources.
When to revisit
Revisit this migration runbook monthly during the first phase after a move, then at least quarterly once the environment is stable. The purpose is not to repeat the migration, but to confirm that the recovery and operational assumptions remain true.
At each review, check:
- Whether backups completed and whether a recent restoration test succeeded.
- Whether DNS records, certificates, firewall rules, access keys, and monitoring still match the documented design.
- Whether storage growth, traffic, CPU, memory, database size, and backup duration are approaching agreed limits.
- Whether latency and availability remain acceptable from the regions that matter to users.
- Whether provider, facility, network, data residency, or compliance requirements have changed.
- Whether rollback instructions and emergency contacts still work.
Trigger an additional review after a major application release, provider change, data centre incident, network redesign, security event, database upgrade, or significant traffic increase. If the current provider is no longer meeting operational needs, compare alternatives using the same workload requirements rather than switching on headline specifications alone. For location and latency decisions, review how to choose a data centre location for low-latency hosting and test from multiple regions.
Before closing the next change window, update the inventory, record the actual timeline and issues encountered, and schedule the next backup restoration test. A migration is complete only when the new environment is documented, monitored, recoverable, and understood by the people responsible for operating it.
