Kubernetes has become the default answer to just about every infrastructure question, which is precisely the problem. The question that matters is not “is Kubernetes good technology” (it is), but “does my organisation have a problem that Kubernetes solves, today, with the team I actually have”. Here is how I answer that before a first conversation even happens, and how you can answer it yourself.
The wrong indicator: the size of the infrastructure
The number of servers says almost nothing. An infrastructure of several dozen VMs may only need a bit of order (automation scripts, tested backups, monitoring that alerts for good reasons), while a handful of machines with no orchestration at all can turn every deployment into a risk. Kubernetes answers a problem of repeated operations at a pace that exceeds what a human team can make reliable by hand, not a problem of volume.
The 4 signals that actually count
The rate of change exceeds what can be verified manually. If every deployment requires a checklist that only one person knows by heart, and that person goes on holiday once a year, the problem is not the size of the estate: it is the absence of reproducibility. Kubernetes formalises what a human does from memory.
High availability is a real requirement, not a checkbox. If a one-hour outage has a measurable cost (lost orders, contractual penalty, reputation), automatic failover and load balancing become investments that pay for themselves. If a one-hour outage on a Tuesday evening bothers nobody, the calculation changes entirely.
Several environments have to stay consistent with each other. Dev, staging and prod drifting apart over time because each one is configured by hand is a debt that grows silently. Kubernetes, combined with infrastructure as code, forces that consistency, but only if the team accepts the discipline that comes with it.
The team has (or can build) the capacity to operate the platform, not just to get it running on cutover day. This is the most frequently ignored criterion and the most decisive one. An unmaintained Kubernetes cluster becomes more fragile than the VMs it replaced: it is a second platform to operate, not just a new box on the technical org chart.
A simple calculation before deciding
Estimate the current annual cost of your situation: hours lost on repetitive manual interventions, the cost of avoidable incidents (team time spent plus business impact), and the implicit risk premium of having one or two people concentrating the critical knowledge. Compare it to the cost of a gradual migration spread over several months, plus the cost of operating a cluster (which is not zero: somebody has to understand it). If the second figure vastly exceeds the first over a two- or three-year horizon, the honest answer is to wait, or to deal first with the root causes (untested backups, no scripts, silent monitoring) that would leave a Kubernetes migration just as badly handled as the existing setup.
What makes a migration premature
Three situations come up often. A team of two or three people with no identified platform engineer: Kubernetes adds a rare skill to maintain, when the real need is often more disciplined infrastructure as code on the existing estate. A monolithic application that does not need to be split up: containerising a monolith without re-splitting it brings neither scalability nor extra resilience, just one more abstraction layer to operate. And pressure from fashion rather than an identified problem: “our competitors are on it” is not a requirements document.
What makes a migration necessary, not just desirable
Conversely, when high availability is already bolted together with fragile home-made solutions, when service discovery happens through configuration files copied by hand between environments, or when every seasonal load peak turns the team into firefighters, the question is no longer whether, but when and how to migrate without stopping everything during the transition.
How to decide without taking my word for it
Run this framework past somebody with nothing to sell: your lead dev, a peer from another industry, or a properly scoped external audit (not an audit that automatically leads to a sale). A simple test for judging any opinion on the subject, mine included: if the answer to “could a generic tool have produced this answer without knowing my context” is yes, be wary of the source.
If the diagnosis leans towards yes, the logical next step is a detailed scoping exercise rather than a decision made on the strength of a blog post: that is exactly the purpose of the modernisation diagnostic I offer ahead of any engagement, precisely so the call gets made before anything heavier is committed to.