What we check before recommending Kubernetes to a client

We are a cloud infrastructure consultancy, and roughly a third of the engagements that come to us asking for a Kubernetes migration end with us recommending against it, at least for now. This is the checklist we actually run before proposing it.

Do you have more than one service that scales independently?

If a single service or two handles nearly all production traffic, the operational overhead of a Kubernetes cluster rarely pays for itself compared to a simpler managed container platform.

Does someone on the team already understand it, or will you be learning it in production?

The incidents we get called in to fix most often trace back to a team that adopted Kubernetes with nobody on staff who had operated it before, under real production pressure. The learning curve is real and it is safer to climb it before you depend on the system, not during an outage.

Is your actual bottleneck infrastructure, or is it something else?

We have seen teams propose a Kubernetes migration to solve a deployment process that was slow because of manual approval steps, not infrastructure. No orchestration platform fixes a process problem.

• Count your genuinely independent scaling units before estimating cluster size — most companies overestimate this.

• Budget for a dedicated platform role, even part-time, or expect the cluster to accumulate unmanaged complexity fast.

• Pilot with one non-critical service for at least a full quarter before migrating anything customer-facing.

When all three checks come back positive, Kubernetes has been worth it for every client we have recommended it to. When even one comes back negative, we say so, even though the migration project would have been the larger and more profitable engagement for us.