Moving Between Cloud Providers Without Downtime

Defining "without downtime"

Before designing anything, agree what the phrase means for this system. Three definitions are commonly meant and they lead to very different projects.

Zero user-visible interruption means requests are served continuously throughout, with no error page at any point. This is achievable for stateless web tiers and much harder for the database beneath them.

A brief write freeze means reads continue and writes pause for a short, announced interval. For most business systems this is the pragmatic target, and it costs a fraction of the effort of true zero downtime.

No data loss with a short outage is the third, and for internal systems it is often entirely acceptable. Deciding which you are buying, and what it is worth, is the first architectural act of the project.

The parallel run

Every low-downtime move has the same shape. You build the destination fully, run both environments at once for a period, shift traffic gradually, and keep the ability to shift it back.

That implies the destination must be built and validated well before the move. Not a proof of concept, but the real thing: same runtime versions, same configuration management, same monitoring, same backup jobs. Anything you skip here appears during the window, when there is no time for it.

It also implies a connection between the two estates. Usually that is an encrypted tunnel over the internet, a WireGuard or IPsec link between the private networks, since replication traffic should not traverse the public internet in the clear. Check the ports and routes early, because firewall changes at two providers are a slow conversation.

Build the destination from code rather than by clicking. A second environment created by hand will differ from the first in ways nobody discovers until traffic arrives, and the reasoning is covered in our introduction to infrastructure as code.

Getting the data across and keeping it current

Data is the component that makes this hard, because it keeps changing while you copy it. The pattern is always bulk seed followed by continuous catch-up.

The database strategies and their downtime profiles deserve their own treatment, and they are set out in database migration strategies. The bulk transfer mechanics and their cost are covered in moving data between cloud providers.

Shifting traffic gradually

Three mechanisms move users from one estate to the other, and they differ mainly in how quickly you can reverse the decision.

Weighted DNS is the simplest. Route 53, Azure Traffic Manager and Cloud DNS all support returning different answers in proportion. Shift a small percentage, watch, increase. The weakness is that DNS changes take effect on the resolver's schedule, not yours, so reversing is slow even with a low time-to-live.

A proxy or reverse proxy layer in front of both estates gives you instant, precise control. Traffic hits one entry point, which forwards to old or new by rule, header or percentage. Reversal is a configuration reload. The cost is an extra hop and an extra component to run.

Application-level routing shifts specific features or tenant groups rather than a percentage of requests. It is the safest option for a multi-tenant system, because you can move one customer, verify, and continue.

Whichever you use, keep sessions out of the application instances first. If a user's session lives in memory on an old server, moving their next request to a new one logs them out and makes gradual shifting impossible.

The egress bill nobody budgets

Leaving a provider means paying to take your data with you. Outbound transfer is metered on the source side, and for a large dataset the one-off charge can be a meaningful share of the project cost.

Calculate it before you plan, not during. Take the dataset size, add the replication traffic that will flow during the parallel run, and add the duplicated traffic during the shifting period when both estates are serving. That total is the number to budget, and the pricing structures are explained in egress costs.

Two tactics genuinely reduce it. Prune before you copy, because old logs, stale backups and abandoned buckets are frequently a large share of the volume. And compress in transit where the tooling supports it, particularly for text-heavy data such as database dumps.

The switch itself

Even a gradual migration has one moment that cannot be gradual: the promotion of the new database to primary. Everything else is choreography around that instant.

A workable sequence is to stop writes at the source, wait for replication lag to reach zero, verify row counts and a sample of checksums, promote the destination database, point the destination application at it, run smoke tests, then release writes on the new side. Announce the write freeze in advance and keep it short.

Leave the source database running and readable but no longer written to. It is your comparison reference for the following days, and reconciling a suspicious report against it is far easier than reasoning from a backup file.

Have the reverse path defined before you begin. The point of no return is normally the moment writes land on the new primary, and what happens after that is the subject of migration testing and rollback plans.

Winding the old estate down

Resist the urge to delete quickly. Run the old environment in a reduced, isolated state for an agreed period, long enough to include at least one full monthly cycle of scheduled jobs.

Work through a decommission checklist rather than deleting by memory: revoke API keys pointing at the old account, remove the old addresses from partner allowlists, cancel support plans and commitments, take a final archival backup, and only then destroy resources. Close the account last of all.

Watch for outbound integrations that still reference the old estate. Webhook endpoints registered with payment providers, DNS records for subdomains nobody remembered, and monitoring probes are the usual stragglers.

If the destination is a different class of provider rather than a like-for-like move, the differences are worth reviewing in advance; the Google Cloud and DigitalOcean comparison illustrates how far the operating models can diverge, and the DigitalOcean account listings describe the destination side of that particular move.

Key takeaways

• Define which kind of "no downtime" you are buying before designing anything; a short write freeze is usually the sensible target.
• Build the destination from code, validate it fully, and connect the two estates over an encrypted tunnel for replication.
• Seed data in bulk, then keep it current with replication or repeated incremental passes; drain queues rather than copying them.
• Shift traffic with weighted DNS, a proxy layer or per-tenant routing, and externalise sessions first so users are not logged out.
• Budget the egress charge explicitly, including replication and the duplicated traffic during the parallel run.
• Decommission on a checklist after a full monthly cycle, and close the old account last.

For platform specifics on traffic shifting, see the Route 53 weighted routing documentation and the Azure Traffic Manager routing methods.