Moving between providers is mostly not a technical problem. The servers are the easy part; the difficulty is in the things nobody wrote down — a cron job, a firewall exception, a certificate, a webhook pointing at an IP address.
Start with an inventory
Before touching the new provider, list what exists. Anything missing from this list is what will break at cutover.
- Every running service and the port it listens on.
- Every scheduled job, including the ones in application code rather than crontab.
- Every external integration and what address or hostname it targets.
- Every DNS record, with its current TTL.
- Every certificate and its renewal mechanism.
- Every credential, and where it is stored.
- Every firewall rule and where the source ranges came from.
Producing this list is often the single most useful part of the whole exercise, regardless of whether you migrate.
Rebuild rather than copy
Lifting a disk image between providers usually works and carries every piece of accumulated drift with it. Rebuilding from a script — even a plain shell script — gives you a documented environment and a repeatable one. If configuration management already exists, this step is nearly free.
Where a like-for-like copy genuinely is required, both environments should at least run the same operating system version so the differences are yours rather than the distribution’s.
Data is the hard part
Files are straightforward. Databases are not, because the database keeps changing while you copy it.
- Take a full dump and restore it into the new environment.
- Set up replication from old to new if the database supports it, so the gap stays small.
- If replication is not available, plan a short write freeze for the final delta.
- Verify row counts and a checksum on the largest tables before trusting the copy.
Copying the data across providers is egress on the source side, and for a large dataset that is a real number worth estimating before the day.
Lower the TTL a week in advance
This is the step that makes cutover reversible. Reduce DNS record TTLs to a few minutes at least 48 hours before the migration — longer if the current TTL is a day, because resolvers hold the old value for the old TTL. At cutover the change then propagates in minutes, and so does a rollback.
The cutover sequence
- New environment running and reachable, tested directly by IP or a temporary hostname.
- Old environment still serving all traffic.
- Final data sync, with a brief write freeze if required.
- DNS switched.
- Both environments left running while traffic drains from the old one.
- Old environment kept for at least a week after the last request, then decommissioned deliberately.
Keeping the old environment alive is what turns a migration into a low-risk change. Deleting it the same evening is what turns a small problem into an incident.
What usually goes wrong
- Something in the world had the old IP address hard-coded — a partner’s allow-list, a payment gateway, a monitoring check.
- Outbound mail stops, because the new IP has no reputation and the provider blocks the port by default.
- A cron job runs on both machines for a week and does its work twice.
- A certificate renewal was tied to the old server’s filesystem.
- Backups were configured on the old host and never recreated on the new one.
Where to go next
- Multi-provider cloud strategy: the practical version
- How to choose a cloud provider
- Compare providers side by side
Questions
Frequently asked
How long before a migration should I lower DNS TTL?
At least 48 hours, and longer than the current TTL. Resolvers keep the old value for the full old TTL, so lowering it the morning of the cutover has no effect.
Should I copy the disk image or rebuild the server?
Rebuild where you can. A copied image carries every undocumented change with it; a rebuild from a script leaves you with a documented, repeatable environment.
How do I migrate a database without downtime?
Dump and restore, then replicate from old to new so the gap stays small, then switch. Where replication is not possible, a short write freeze for the final delta is the usual compromise.