Cloud Migration Without the Rewrite

Cloud migrations rarely fail for technical reasons. They fail because two different projects got merged into one and given a single deadline.

Project one is moving what you have to somewhere else. Project two is redesigning it to work the way cloud systems are supposed to work. Both are legitimate. Doing them simultaneously is where the schedule dies.

Move first, improve second

The unglamorous approach is to move the system roughly as it is, get it running, prove it is stable, and only then start changing its shape.

This is unfashionable because it means running things in the cloud that are not particularly cloud native for a while, which offends people's sense of craft. It is also dramatically more likely to succeed, for one reason: when something breaks after a like-for-like move, you have a short list of suspects. When something breaks after a simultaneous move and redesign, everything is a suspect.

Separating the two also means you can stop after phase one if the business needs you elsewhere, and still have delivered something.

The costs that surprise people

Data transfer out. Moving data into a cloud provider is usually cheap or free. Moving it out is not. This matters for backups stored elsewhere, for analytics pipelines, and enormously if you ever want to leave.

Idle resources. On your own hardware, an oversized server costs the same whether busy or not, so nobody thinks about it. In the cloud it bills continuously. Environments that were fine to leave running now cost money every hour.

Managed service pricing curves. Managed databases and queues are excellent and priced to be cheap at small scale. Some of them get expensive faster than your usage grows. Model this at three times your current load before committing.

What genuinely gets better

It is worth being clear that the cloud does deliver real things, because the sceptical version of this article overcorrects.

You get elasticity, which matters if your load is uneven. You get managed services that remove entire categories of maintenance work. You get the ability to create a full environment in minutes, which changes how teams test. And you get infrastructure defined in code, so the environment stops being a thing that exists only in one person's memory. That last one also opens the door to automating routine operational work that previously required somebody to log in and click.

Those are substantial. They are just not automatic, and none of them arrive on migration day.

The rehearsal

The single highest value activity in any migration is the practice run.

Move a full copy, with real data volumes, into the new environment. Run it. Time it. Break it deliberately and recover it. Then throw it away and do the real one.

Almost every unpleasant surprise shows up here rather than during the real migration, at a moment when nothing is at stake. Teams that skip the rehearsal because of schedule pressure reliably spend more time than the rehearsal would have taken.

Leaving the door open

Decide early how much provider-specific technology you are willing to adopt.

Using a provider's managed offerings is often the right choice, and pretending otherwise leads to rebuilding things badly in the name of portability. But it should be a decision someone made deliberately, with an understanding of what leaving would involve, rather than something that happened by accident across forty small choices.

Write it down. Two paragraphs is enough. The value is in having had the conversation.

Afterwards

The migration ends. The operating does not.

A system in the cloud that nobody watches is a system that costs more and breaks in new ways. Monitoring, cost review, and patching move from being occasional tasks to continuous ones, which is the part of managed IT services that actually justifies the retainer. And if the migration surfaced an application that fights the environment at every turn, that is a software problem wearing an infrastructure costume.