On-premise to cloud: moving systems that are not allowed to stop

Most cloud migration guidance assumes you can schedule downtime. Announce a maintenance window, stop the system, copy the data, start it in the cloud. For a billing platform, a toll transaction backend, or a payment pipeline, that assumption fails on the first line: the system earns money every second it runs, and some of them carry contractual availability clauses with penalties attached. An on-premise to cloud migration for this class of system is a different engineering problem, and this article covers the parts that make it different: cutover windows, dual-run validation, replication and re-synchronization, the rollback plan, and the go/no-go decision itself.

What changes when the system cannot stop

A conventional lift-and-shift tolerates a gap. You freeze writes on Friday evening, transfer the data, validate over the weekend, point the clients at the new environment on Sunday night. If validation takes longer than planned, the window stretches and users complain on Monday.

A transactional system removes the gap. Toll gantries register vehicles around the clock. Usage records arrive from the network whether or not your migration is in progress. Every minute the system is down is revenue that either disappears or piles up in buffers that must be drained and reconciled later. The migration therefore has to satisfy two constraints at once: the data in the cloud target must be complete and provably identical at the moment of switchover, and the switchover itself must fit inside a window measured in minutes.

Those two constraints drive every design decision that follows. You cannot copy terabytes of data in minutes, so the bulk of the data must move while the source keeps running, which means continuous replication. You cannot validate a billing engine in minutes, so validation must happen before cutover, against real traffic, which means a dual-run phase. And because a compressed window leaves no time for debugging, the cutover has to be a rehearsed script with a decision framework, and a way back that is tested rather than assumed.

Replication first: moving the data while the system runs

The pattern that makes a near-zero-downtime migration possible is initial bulk load plus continuous change capture. You take a consistent snapshot of the source database and restore it in the cloud. From the snapshot's log position onward, change data capture streams every subsequent insert, update, and delete to the target. The cloud copy trails production by seconds, and stays that way for as long as you need.

The tooling is mature: log-based CDC through Debezium and Kafka, native logical replication in PostgreSQL, Oracle GoldenGate, or the managed migration services of the cloud providers. The tool matters less than the properties you verify. Replication lag must be measured continuously, because the lag at cutover time defines your minimum window: you stop writes on the source, wait for the target to drain the last changes, and that wait is downtime. Schema differences between source and target must be handled explicitly, since a heterogeneous migration, Oracle to PostgreSQL for instance, adds type conversion and edge cases that only surface under real data. And the replication path itself needs monitoring and alerting, because a silently stalled stream discovered on cutover night ends the attempt.

One discipline pays for itself many times: continuous row-level reconciliation between source and target during the whole replication phase. Count-based checks catch gross failures; checksum-based comparison per table and per time range catches the subtle ones, a trigger that did not fire, a type conversion that truncated, a timezone shifted by two hours. Every discrepancy found during replication is one you will not find during cutover, when there is no time to look.

Dual-run: the cloud target earns trust on real traffic

Test environments do not prove a billing system. Production traffic contains the malformed record from a partner feed, the tariff edge case from a contract signed years ago, the burst pattern at the top of the hour. The only environment that contains production's surprises is production, and the way to use it without risk is a dual-run in shadow mode.

During dual-run, the on-premise system remains authoritative. It receives the traffic, produces the results, and serves the downstream consumers as always. The cloud target receives a copy of the same traffic, processes it in parallel, and its output is compared against the authoritative result record by record. Divergences are logged, triaged, and driven to zero. No customer, auditor, or downstream system ever sees a number produced by the unproven side.

Three practical points decide whether dual-run delivers its promise. First, the comparison must be automated and complete: sampling a few invoices by hand builds confidence, and misses the one-in-a-million case that becomes a revenue dispute. Compare every computed amount, every aggregate, every generated record, with tooling that outputs a divergence report per day. Second, expect legitimate divergences and classify them. Some differences come from floating-point rounding, ordering effects, or defects in the legacy system that the new implementation quietly fixed. Each class needs a documented decision: accept, align, or fix. An unexplained divergence is a defect until proven otherwise. Third, run the dual-run long enough to cover the system's natural cycles. A billing platform has month-end. A toll backend has weekend peaks and holiday patterns. Two clean weeks that miss a month-end close prove less than they appear to.

Dual-run costs real money: two environments at production scale, traffic duplication infrastructure, and engineering time on divergence triage. For a system whose errors are measured in euros, it is the cheapest insurance available, and it doubles as the load test, since the cloud target has by definition already handled production volume before it becomes authoritative.

The cutover window: minutes, scripted, rehearsed

With replication holding the data current and dual-run holding divergence at zero, the cutover itself shrinks to a short, mechanical sequence: stop writes on the source, confirm the replication stream has drained, run the final integrity checks, switch the entry points to the cloud environment, and watch the first transactions land.

Compressing that sequence safely takes preparation that has little glamour. The sequence is a written runbook where every step has an owner, an expected duration, a verification command, and an abort path. Entry-point switching is designed for speed and reversibility: short DNS TTLs set days in advance, or better, a routing layer or load balancer where the switch is one configuration change instead of a cache expiry you cannot control. Buffering at the edges covers the gap, because gantries, meters, and partner feeds keep producing during your window; queues absorb the minutes of switchover and drain into the new system afterward, so the window creates latency instead of loss.

Then rehearse. A full dress rehearsal against a production-scale copy, timed step by step, at least twice. The first rehearsal fails somewhere: a script that assumes a hostname, a grant missing on the target, a drain step that takes eleven minutes instead of two. Every failure found on a Tuesday afternoon is one removed from the night that counts. Teams that skip rehearsal because the runbook looks complete are choosing to run their first test in production.

The rollback plan, and why it includes reverse replication

A rollback plan that says "point the routing back at the old system" is half a plan. The moment the cloud environment becomes authoritative, it starts accepting writes the on-premise system never sees. Roll back an hour later without accounting for that, and you restore service on a system missing an hour of transactions: a data loss incident layered on top of a failed migration.

The complete plan runs replication in reverse. Before cutover, you configure and test change capture from the cloud target back to the on-premise source, and you start it the moment the cloud side goes live. During the early authoritative period, the old system trails the new one by seconds, exactly as the new one trailed the old during preparation. A rollback then becomes the same drill in the opposite direction: stop writes, drain the reverse stream, verify, switch the routing back. Losing nothing on the way down is what makes the decision to roll back takable at all.

Two details are routinely missed. Define in advance how long the rollback capability stays armed: keeping the old environment synchronized and operable for an agreed period, often two to four weeks through the first billing cycle, and naming the criteria for standing it down. And test the reverse path before cutover night, because an untested rollback is a hypothesis, and cutover night is a poor time to test hypotheses.

Go/no-go: deciding under pressure without improvising

The final failure mode is human. It is 2am, the team has prepared for months, a checksum mismatch appears on one table, and someone senior says it is probably fine. Sunk cost and fatigue push hard toward "go", which is precisely why the decision must be designed before the night begins.

A working go/no-go framework has three parts. Measurable criteria written weeks in advance: replication lag at zero and verified, integrity checks green across all tables, dual-run divergence at zero or within a pre-agreed tolerance for pre-agreed reasons, monitoring live on the target, rollback armed and tested, the named decision-makers present. Binary evaluation: each criterion passes or fails, and a failed criterion means no-go by default, with any exception argued for in writing before the window, never during it. And a blameless abort: a no-go consumes the window and costs a few weeks, while a bad go on a revenue system can cost an audit finding and months of reconciliation. Teams abort well when aborting is treated as the system working.

Hold the same discipline after the switch. The first hours on the new environment are an extended verification with the rollback still armed: transaction rates compared against the same hour last week, error rates, end-to-end latency, and the first reconciliation runs against expected totals. The migration is finished when the first full billing cycle closes clean, and only then.

Where DNA Solutions fits

DNA Solutions runs on-premise to cloud migrations for billing, tolling, and transaction platforms where downtime has a contractual cost: replication design, dual-run validation, cutover runbooks, and tested rollback paths, on Oracle, PostgreSQL, Kafka, and the major cloud platforms. We have moved systems that process hundreds of millions of euros per month in audited transactions, and we plan every migration around the assumption that cutover night will surprise us somewhere. If you are planning to move a system that is not allowed to stop, schedule a technical discussion and we will review your cutover and rollback design.