Moving to another provider without losing a URL

Everything moves eventually

Prices change, a free tier ends, a provider is acquired, a region closes, or the thing you chose at the start no longer fits. Migration is not a failure; it is a normal event in the life of a system that survives.

It is also where small projects lose data and break links, because the work is done in the wrong order.

The order that works

1. Stand the new thing up in parallel. Nothing is switched. Deploy the application to the new provider, point it at a copy of the data, and use it yourself on a temporary hostname.
2. Copy the data, then keep it in sync. For a database, a dump and restore establishes the baseline; logical replication or change-data-capture keeps it current so the final cutover moves minutes of data rather than hours.
3. Lower the DNS TTL first. Days in advance. A record with a 24-hour TTL takes up to a day for the last resolver to notice a change; a 60-second TTL makes the cutover reversible in a minute. This step must happen before everything else, and it is the one most often forgotten.
4. Run read traffic against the new system while writes still go to the old one, if your architecture allows it. Any difference in behaviour appears here, without risk.
5. Cut over during your quietest hour, with the old system still running and still receiving data.
6. Watch for a day, then a week, before decommissioning anything.
7. Keep the old system’s data, offline, for a month after you turn it off.

The stateless half is easy; the state is the migration

Moving an application is a deploy to a different place. Moving a database is the actual project, and there are three approaches:

• Downtime window. Stop writes, dump, restore, start. Simple, honest, and fine if you can afford ten minutes at 4am and your data is small. Rehearse it and time it first.
• Logical replication. The new database subscribes to the old one’s changes and stays current; you cut over when the lag is near zero. Standard in Postgres and MySQL, and the right answer above a few tens of gigabytes.
• Dual write. The application writes to both, reads from one. Powerful, and the most error-prone of the three, because partial failures produce divergence. If you use it, add a comparison job that reads from both and reports differences, or you will find the divergence months later.

File storage has a fourth trick worth knowing: copy everything in advance, then keep serving reads from the old bucket while new writes go to the new one, and run a background copy for the remainder. S3-compatible tooling (rclone is free and excellent) makes this a single long-running command.

The costs that appear at the door

Egress is charged on the way out. Moving 5 TB off a provider that charges 9 cents a gigabyte is about $450, payable before you have benefited from the move. Check that number early; occasionally it changes the plan, and occasionally the destination provider will cover it, which is worth asking.

There are also regulatory rules in some places designed to reduce switching costs for cloud customers, and the picture varies by jurisdiction. Do not rely on it; budget for the bill.

URLs are the thing you must not break

Every link somebody saved, every search result, every citation of your content is a URL. Losing them is the one migration cost you never recover, because the traffic stops and nobody tells you.

• Keep the same paths if you possibly can.
• Where paths must change, serve 301 redirects from every old URL to its new one, and keep them for years, not months.
• Check redirects with a crawler before and after: free tools will fetch your sitemap and report every non-200.
• Do not move the domain and the platform at the same time. One change at a time, a week apart, so you know which one caused the problem.

Write the rollback down first

Before the cutover, one page: what “go back” means at each step, who decides, and what the deadline is. In practice it is usually “change the DNS record back and stop writes to the new system”, which only works if the old system is still running and still has current data, which is why steps 5 to 7 above are in that order.

A migration where the old system was decommissioned on the same day is a migration with no undo, and it is the reason most horror stories about this exist.