Moving to the Cloud Without Downtime: A Migration Playbook
Plenty of organisations know they need to get off the ageing server humming in the back office, and put it off anyway. The reason is almost always the same fear: the image of a single, terrifying cutover weekend where everything moves at once, something breaks at 2am, and Monday opens with no system. That all-or-nothing picture is what kills cloud projects before they begin.
It's also avoidable. The professional way to migrate isn't a leap; it's a sequence of small, reversible steps.
Lift-and-shift versus re-architect
There are two broad ways to move. Lift-and-shift takes the existing system roughly as-is and runs it on cloud infrastructure — fast, low-risk, and the right call when the priority is getting off failing hardware quickly. Re-architecting rebuilds the system to use cloud services properly — more work, but it's where the real gains in cost, scale and resilience live.
It's not a religious choice between them. Most sound migrations do both in sequence: lift-and-shift to get safe, then re-architect the parts that justify it, once you're no longer fighting a dying server room.
The strangler-fig approach
The technique that makes migration safe has an odd name — the strangler fig, after the plant that grows around a tree and gradually takes its place. Applied to systems, it means standing up new cloud services that take over the old system's functions one at a time, while the legacy system keeps running everything it still owns. Traffic shifts to each new piece only once it's proven.
Function by function, the new system grows and the old one shrinks, until one day the legacy system isn't doing anything important and can be retired quietly. There's no dramatic switch-over, because the switch happened gradually and was tested at every step.
Cutover, cost and security
Done this way, each phase is small enough to test thoroughly, prove in production, and roll back if it misbehaves — so risk is always contained to one piece, and the business keeps running throughout. There's no heart-attack weekend because there's no single weekend that matters.
And the work doesn't end when the last function moves. The cloud only pays off if you then right-size what you're running — switching off the over-provisioned resources that quietly burn money — and harden security for the new environment rather than assuming the old assumptions still hold. That after-care is where a migration turns from "we moved" into "we're better off." It's how we run cloud migrations at Appcellen: phased, reversible, and tuned after the move, not abandoned at cutover.
