Zero-Downtime Cloud Migrations
Some systems cannot be switched off for a weekend. We migrate them while they keep serving customers, with a rollback path at every step.
Why weekend maintenance windows stopped working
There was a time when you could put up a maintenance page on Saturday night and be done by Monday. That still works for internal tools with a single timezone. It does not work for a store, a customer-facing platform, or anything with an SLA attached to it.
The cost of downtime is rarely the outage itself. It is the orders that were not placed, the support tickets that follow, and the fact that a planned window has a habit of turning into an unplanned one when the restore takes longer than the estimate. So the question is no longer how to schedule downtime. It is how to avoid needing it.
What a zero-downtime migration actually involves
The idea is straightforward. Instead of stopping the old system and starting the new one, you run both, keep them in sync, and move traffic across gradually.
The work is in the details. The new environment has to be a genuine equivalent, not an approximation: same runtime versions, same environment variables, same certificates, same scheduled jobs. Data has to flow continuously from old to new with replication lag low enough that switching is safe. Traffic has to be shiftable in small increments, which usually means a load balancer, a proxy, or DNS with a short TTL that was lowered days in advance rather than an hour before.
And every stage has to be reversible. If the new system starts returning errors at five percent of traffic, you move that five percent back and investigate with no customer impact. That property is what makes the whole approach worth the extra effort.
The database is the part that decides everything
Application servers are easy to move. They are stateless, you can run ten of them, and nobody notices which one answered.
Databases are the opposite. There is one authoritative copy, it is constantly changing, and the moment two systems both think they are authoritative you have a data problem that is far more expensive than an outage. This is where migration plans succeed or fail.
The usual approach is continuous replication from the old database to the new one, running long enough that lag is consistently low, followed by a short, carefully sequenced switch of the write path. We rehearse that sequence against a restored copy of production before doing it for real. Rehearsal is not optional here. It is the only way to find out how long the switch actually takes on your data volume rather than on an estimate.
What we check before agreeing to switch
A cutover is a decision, and it should be made against evidence rather than a calendar date. Before we shift meaningful traffic, we want to see the new environment handling a realistic load, replication lag stable and low, backups taken and restored successfully on the new platform, and monitoring reporting the same metrics you were watching on the old one.
If any of those are missing, the sensible move is to wait. A migration that slips by a week costs far less than one that goes ahead on a system nobody can observe.
When downtime is the cheaper answer
Not every system justifies this. If you run an internal tool used by thirty people in one country, a two-hour Sunday window is simpler, faster, and less expensive than building a parallel environment and a staged traffic shift. Complexity has a price, and it is worth paying only where continuity genuinely matters.
We will tell you which category your system falls into during scoping. Some clients arrive expecting a zero-downtime project and leave with a much smaller plan, because that is what their situation actually needed.
What you get
Dependency map of the current system
Before anything moves we document what talks to what, including the integrations nobody remembers. Most migration incidents trace back to a connection that was never on the diagram.
Target environment built in parallel
The new infrastructure is stood up alongside the old one and exercised with real workloads, so the cutover is a routing change rather than a first run.
Data replication and cutover plan
Continuous replication keeps the two systems in sync until the switch, with a written sequence for the switch itself and for reversing it.
Gradual traffic shift
Traffic moves in increments rather than all at once, so a problem shows up on a small slice of users instead of all of them.
Monitoring in place before the switch
Error rates, latency and queue depth are instrumented on the new stack first. You cannot judge a cutover on a system you cannot see.
Decommissioning of the old stack
The legacy environment is retired deliberately after a defined observation period, not left running quietly and billing you for another year.
How we work
- 01
Inventory and risk assessment
We map services, data stores, scheduled jobs and third-party integrations, then rank them by how badly a failure would hurt. That ranking decides the migration order.
- 02
Build and validate the target
Infrastructure is defined as code and deployed to the new platform. We run load tests and restore a real backup into it before any production traffic gets near it.
- 03
Synchronise the data
Replication runs between old and new until lag is measured in seconds. This is usually the longest phase and the one that decides whether the cutover is boring.
- 04
Shift traffic in stages
A small percentage first, then wider, watching error rates and latency at each step. If something moves in the wrong direction we shift it back.
- 05
Stabilise and retire
We keep the old environment reachable through an agreed observation window, then shut it down and remove the cost.
Tools and technology
Where a solid open-source tool exists, we choose it over a closed one. No lock-in to a single vendor, and costs you can actually predict.
- OpenTofu
- Terraform
- Docker
- Kubernetes
- PostgreSQL
- Debezium
- Grafana
- Prometheus
- AWS
- Microsoft Azure
- Google Cloud
- Cloudflare
Frequently asked questions
Related work
More services in this category
Incremental Cloud Migrations
Not everything has to move at once. We migrate system by system, starting with whatever is hurting most, so you see results long before the project ends.
Infrastructure Modernization Sprints
A short, focused engagement that fixes the infrastructure problems actually costing you something, without committing to a project that runs for months.
Serverless Architecture and Scale-to-Zero
Your code runs when it is needed and costs nothing when it is not. For workloads with uneven traffic, that changes the economics of running a system.
Read testimonials from companies that trusted us
Delivered well ahead of the deadline.
ZanReal's individual approach is impressive.
Knowledge and business intuition make them a valuable partner.
Quick solutions that reduced costs by 99%.
Is there a system you cannot afford to switch off?
Message usTell us what it runs on and what depends on it, and we will outline a migration plan with a rehearsed rollback at every step.
Can't keep up with changes in AI world?
Let us do the heavy lifting. Every week we distill the most important AI developments into a focused 5-minute briefing — so you stay ahead without the noise.
Find out more