10.5 Migrating existing systems

What this is and why it exists

Most cloud work in the world is not building something new; it is moving something that already exists, that people depend on, that nobody fully understands any more. This lesson is how that is done without a heroic weekend: the six things you can do with each system, the discovery that must come first, a cutover with a way back, and the honest reason that the simplest strategy is frequently the most expensive one.

The vocabulary

• Rehost (lift and shift) — move the system as it is onto rented machines, changing nothing.
• Replatform — move it, changing a few things to use managed services: the database, the load balancer.
• Refactor — rework the application to suit the cloud properly.
• Repurchase — replace it with a bought product and stop running it at all.
• Retire — turn it off, because nobody actually needs it.
• Retain — leave it where it is, for now, on purpose.
• Discovery — finding out what exists and what depends on what, before deciding anything.
• Cutover — the moment traffic moves from old to new.

The mental model

Six choices, applied per system rather than per project, and the two everybody forgets are the cheapest. Retire first: in any estate of a decent age, some things serve nobody, and confirming that is the highest-return work in the whole migration — nothing moves faster than something you turned off. Retain second: a system with two years of life left and no problems does not need to be moved this year, and saying so deliberately is a decision rather than a delay. Only then the four that involve work. Repurchase where a bought product does the job. Rehost where you need to be out of a data centre by a date and the system is fine as it is. Replatform where a small number of changes — a managed database, the provider's load balancer — remove most of the operational burden. Refactor only where the system genuinely needs it and will earn back the effort.

Discovery comes before all of it, and skipping it is the single most reliable way to produce the heroic weekend. What is running, what talks to what, what runs on a schedule, what has a hardcoded address, what has a certificate, what has a licence tied to a machine, and who would notice if it stopped. The dependency map is the deliverable, and the parts that hurt are always the same: the batch job nobody mentioned because it runs quarterly, the reporting tool connecting straight to the production database, the fixed IP address in a partner's firewall rule, and the machine whose owner left three years ago. Every one of those is discoverable in advance and disastrous on the night.

Data is the hard part of every cutover, because unlike a server it cannot be copied twice. The safe shape is: replicate continuously from old to new until the gap is small and steady, verify against the copy rather than hoping, then a short pause where writes stop, then let the last changes drain, then point traffic at the new system. The pause is what makes the cutover reasonable rather than terrifying, and it is measured in minutes rather than hours if the replication was already caught up. Do it in a rehearsal first, with the stopwatch, exactly as with a restore drill.

And write the rollback before the cutover, not during it. Keep the old system running and able to receive traffic again for a stated period — the point at which you can no longer go back should be a decision you make later, in daylight, rather than one you discover at midnight. That means knowing what happens to data written to the new system if you do return, which is why the rollback plan usually implies either a short read-only window or accepting that some changes must be moved back by hand. Decide which, in advance, and write down the deadline after which returning is no longer possible.

Then the honest finish. Lift and shift is attractive because it changes nothing, and it frequently costs more than the servers it replaced — because the sizes carried over were chosen for hardware bought years ago and sized for a peak plus fear; because a machine you owned had a paid-for cost while a rented one bills every hour; because nothing was turned off at night; and because none of the managed services that would have removed operational work were adopted. That does not make it wrong: for a hard deadline out of a data centre it is the right call. It makes it a first step. The saving arrives from the right-sizing and the replatforming that follow, and a migration plan that ends at the lift has produced a more expensive version of the old system, in a place where the meter is visible.

What you should now be able to explain or do

Name the six strategies and say which two are cheapest and most often forgotten. Say what discovery produces and name four things it typically finds that would otherwise appear on cutover night. Describe a data cutover with a small, verified gap and a short pause. Write a rollback plan including the deadline after which it expires. Explain, in four reasons, why lift and shift often costs more than the servers it replaced — and when it is nonetheless the right choice.

Check yourself