Cloud migration without the downtime headache

Zero-downtime migration isn't a marketing phrase — it's a specific set of technical patterns, and skipping them is why so many migrations end in a painful weekend cutover.

Why the "big bang" cutover approach fails so often

The instinct for many teams is to build the new environment, test it, and then switch everything over in a single scheduled maintenance window. This works fine for small, simple systems. For anything with real production traffic and data, it concentrates all the risk into a single high-pressure event — if something's wrong, you're debugging under a ticking clock with a business waiting on you, which is exactly the wrong conditions for careful troubleshooting.

The pattern we use instead: strangler-fig migration

Rather than a single cutover, we migrate incrementally using a pattern sometimes called strangler-fig: new functionality gets built and deployed on the new infrastructure first, while old functionality continues running on the existing system, with a routing layer (often a reverse proxy or API gateway) directing traffic to whichever system currently owns a given piece of functionality. Over time, more functionality moves to the new side until the old system is handling nothing and can be decommissioned — with no single moment where everything switches at once.

For data migration specifically, we run dual-write periods: the application writes to both the old and new database simultaneously for a defined period, allowing us to validate that the new system is producing consistent results before cutting reads over, and providing an instant rollback path (just stop reading from the new system) if a discrepancy shows up.

A concrete example

A healthcare services client needed to migrate a patient scheduling system from on-premise infrastructure to AWS, with zero tolerance for scheduling downtime given active daily clinical use. We built the new system in parallel, used a routing layer to migrate individual clinic locations one at a time rather than all at once (starting with the lowest-volume location to validate the approach), and ran a two-week dual-write period on the patient data before fully cutting over reads. Total migration took 11 weeks from first location to last, with zero scheduling system downtime recorded across the entire process — the worst incident was a 40-second elevated latency period during one location's cutover, invisible to end users.

The rollback plan that has to exist before migration starts, not after something breaks

Every migration step we plan has an explicit, tested rollback procedure defined before that step executes — not improvised if something goes wrong. This sounds obvious but is the most commonly skipped step under deadline pressure, and it's the difference between a bad moment during migration and a genuine incident.

Where teams get stuck

The most common mistake is underestimating data migration complexity relative to application migration. Application code can be tested extensively before cutover; data consistency issues often only surface under real production load and edge cases. We always budget more contingency time for data migration validation than for the application layer, even though the application work often looks more complex on paper.

How Ndakum approaches it

Incremental, low-risk migration is standard practice in our Cloud Engineering work — we plan for zero-downtime as a default requirement, not an optional upgrade.