Five Kubernetes migrations later

I’ve now clocked five projects migrating legacy applications onto Kubernetes. I’m not sure I’d do it a sixth time.

Not because Kubernetes is the wrong technology. It isn’t. It’s still one of the best things to happen to infrastructure. But the landscape it won in has shifted, and the reasons I reached for it don’t hold the way they used to.

Why it made sense

Every one of those five started from the same place: a legacy estate that was hard to deploy, hard to scale and different on every server.

Kubernetes fixed that. One way to package an app, one way to deploy it, one way to scale it, whichever cloud or data centre it ran in. It gave the platform team a standard, and it gave the business a story: modern, portable, cloud-native.

And it worked. Deployments got faster, capacity went up, and the estate finally looked the same everywhere.

What it actually cost

What it also gave us was a platform to run, forever:

• Upgrades. A new version every few months, and the add-ons that have to move with it
• The ecosystem. Ingress, service mesh, secrets, policy, autoscaling, observability. Each one a choice, each one something to patch
• Skills. People who are good at running clusters are expensive and hard to keep
• Cognitive load. App teams who just wanted to ship ended up learning YAML, Helm and why their pod won’t start

None of that is a reason not to use Kubernetes. It’s the price of the control it gives you. The question is whether you still need to pay it.

What’s shifted

Managed containers grew up. When I started, Kubernetes was the only serious way to run containers at scale. Now every cloud has a service that runs a container for you: no cluster, no nodes, no upgrades. For most legacy apps, that’s all they needed.

Platform engineering moved up a layer. The goal was never a cluster. It was a paved road for app teams. Today you can build that road on managed services and keep Kubernetes below the line, or leave it out entirely.

AI changed the maths on modernisation. The expensive part of a legacy migration used to be the code: untangling it, containerising it, making it stateless. With AI in the loop, refactoring and rewriting are far cheaper than they were. That makes “rewrite it for a managed or serverless platform” a real option, where it used to be the fantasy.

Portability matters less than we said it would. Every business case I wrote had “avoid lock-in” in it. In five projects, I can count on no hands the times we actually moved a workload to another cloud.

Kubernetes didn’t get worse. Everything around it got better.

What I’d do now

If I took on a sixth legacy estate tomorrow, I’d start with the simplest thing that runs it:

1. Managed containers first. Package the app, run it on the cloud’s own container service, and stop there if it’s enough.
2. Serverless where the shape fits. Event-driven and spiky workloads often don’t need a container at all.
3. Kubernetes when you can name why. Real multi-cloud or on-prem requirements, very large fleets, or workloads that genuinely need the control. Then it earns its place, and you go in knowing the cost.

It’s the same rule as everywhere else: start with one, prove it, and make every step up earn its place.

So, would I do it again?

For the right estate, yes. But I wouldn’t start there any more. Five times, Kubernetes was the answer before anyone asked the question. Next time, I’ll ask the question first.