Kubernetes gets recommended by default in a lot of architecture conversations, often before anyone’s checked whether the problems it solves are the problems the team actually has. Before scoping a migration, we ask clients to answer these honestly.
Do you actually need to scale independently per service?
If your application is a monolith, or a small number of services that scale together, a simpler container orchestration setup (or even well-configured VMs with autoscaling) gets you most of the operational benefit without the cluster management overhead.
Who’s going to operate the cluster at 2am?
Kubernetes doesn’t remove operational burden — it relocates it, from managing individual servers to managing a cluster control plane, networking, and storage layer that has its own failure modes. If the answer to “who owns this” is vague, that’s a real problem to solve before migrating, not after.
Is your CI/CD pipeline actually ready?
Kubernetes rewards teams with mature CI/CD — image builds, automated rollouts, health checks wired into deploys. If deploys today are still partly manual, fixing that first is usually higher-leverage than the Kubernetes migration itself.
What’s the rollback plan for the migration itself?
Not the application rollback — the migration rollback. Every phase of moving a live service onto a new orchestration layer needs a tested way back to the previous state. If that plan doesn’t exist in writing, the migration isn’t ready to start.
None of this means Kubernetes is the wrong call — for the right shape of system, it’s a substantial operational improvement. It means the decision should follow from these answers, not precede them.