Moving to the cloud is not moving the servers

“Move to cloud”, in many companies, translates into one of two things: putting everything back on infrastructure as a service, virtual machine for virtual machine, or containerising everything as is, with Docker images of several gigabytes that carry the application, its dependencies and a good part of the system that ran it before.

In both cases, you have moved house. You have not migrated

Moving house has a cost, and it is higher than you think. A virtual machine running around the clock at a cloud provider costs more than the same one in a data centre that has already been paid off. A four-gigabyte image builds slowly, deploys slowly, scans badly and starts too late to benefit from the elasticity you came for. And operations have not changed: the same people watch the same machines, with an extra bill.

Migrating is something else. It is asking, service by service, what still deserves to exist as a server: a managed database replaces a machine to administer; a managed message queue replaces a cluster to maintain; a function or a minimal container that starts in a second replaces an image that carries a whole operating system. It is reducing the surface you operate yourself, not relocating it.

That requires touching the application, which is precisely what the move was meant to avoid. But that is where the gains are: in elasticity, in delegated operations, in costs that follow usage. A cloud full of servers ported as they were offers none of that. It offers the same system, elsewhere, at a higher price.

So the right question before a migration is not “how do we port all of this?” but “what do we no longer need to port?”