Moving your system to the cloud without stopping the business

Migrate in stages, with the old system running until the new one proves itself. The order that works is always the same: inventory, containerisation, a parallel environment, data migration last, and a rollback plan written before you start.

Infrastructure migration is one of those projects where success is invisible, nobody notices, and failure turns into a board meeting. The difference between the two rarely comes down to the choice of provider.

First, the honest inventory

Every migration that goes wrong begins with someone assuming they know what is running on the server. Take your time and list:

• Every active process, including that cron job somebody set up in 2016 that nobody understands, which happens to generate the report finance uses on the fifth of every month.
• Every directory written to disk. File uploads cause more migration trouble than anything else, because they vanish from the diagram and reappear in production.
• Every hardcoded address: an IP in a third party’s firewall rule, a certificate, an integration that trusts your outbound IP.
• The real versions of language, database and libraries. “Probably 12” does not count. Check.

That survey takes two to five days and heads off the three most expensive surprises of the final phase.

Containerise before you orchestrate

The temptation is to jump straight to Kubernetes. Do not. The first step is getting the application to run inside a container, anywhere.

That exercise exposes every bit of coupling to the current server: absolute file paths, dependencies installed by hand, an environment variable that only exists on that machine, the system timezone. It is tedious work and it holds half the value of the migration, because you end up with a system anyone can start anywhere.

If a couple of containers behind a load balancer then handles your volume, good news: you do not need an orchestrator. Kubernetes is excellent and carries a very real operational cost. Adopt it when the problem justifies it.

A parallel environment, not a replacement

Stand the new environment up in full while the old one keeps serving. Point a copy of the database at it. Let it run for a week or two with mirrored traffic or internal team usage.

That is when the subtle differences surface. A different timeout. An image library producing slightly different output. A query that was fast on the old disk and is slow on the new storage. Finding that with the old system still running is inconvenient. Finding it on cutover night is something else.

Data last, and rehearsed

The database is always the final piece and the only one without a comfortable undo. The procedure that works:

1. Do the full load ahead of time and keep continuous replication from old to new.
2. Rehearse the entire cutover in a test environment, with a stopwatch. You need to know whether the window is eight minutes or two hours before you promise anything to anyone.
3. On the real cutover: put the system in read-only mode, wait for replication to drain, switch DNS, and validate against a test script written beforehand.
4. Keep the old environment intact and powered down for at least two weeks.

The rollback plan has to be written

This is not pessimism, it is procedure. Before the cutover, the document answers: what is the objective criterion for aborting, who makes that call, which commands to run, how long it takes, and what happens to data written to the new environment while it was live.

If nobody can answer that last question, the cutover window needs to be short enough that the answer is “no meaningful data”. That is why migrations happen at night, not out of tradition.

What actually pays for it

The gain rarely comes from the server bill. Plenty of companies migrate and spend more. The real return shows up elsewhere.

A reproducible environment, first of all: spinning up an identical copy for testing stops being a project and becomes a command. Deploying without fear, because with continuous integration shipping a fix becomes routine instead of an event. A tested recovery, since a backup nobody has restored is not a backup, and in the cloud restoring to verify costs pocket change. And elasticity, if your load is uneven. If it is flat, a dedicated server may well be cheaper, and there is nothing wrong with admitting that.