On-premise or cloud: how to decide when both are reasonable
A practical approach to choosing between local infrastructure and the cloud for companies that do not have an obvious answer.
The debate between "cloud or not cloud" often turns into an ideological argument. One side talks about flexibility and speed, the other about security and control. In practice most companies live somewhere in between: they have both, and new systems need to go somewhere. The right question is not how many servers you have but how fast things can change - and that framing still holds.
I do not believe in a universal answer. But I do have an approach to making this decision for a specific system in a specific situation.
Why there is no universal answer
Cloud and owned infrastructure are optimal for different situations. Neither wins on every dimension.
Cloud wins on speed of start, on the absence of capital expenditure on infrastructure, on elastic scaling. It loses on cost predictability under sustained high load, on vendor dependence, and on the need for reliable connectivity.
Owned infrastructure wins on control, on cost over a long horizon with stable load, on integration with legacy systems. It loses on capital expenditure, on speed of scaling, and on the operational cost of running it.
Most companies already operate in a mixed mode, whether they have named it that way or not.
What to look at for a specific decision
A few practical criteria help.
Nature of the workload. Constant, predictable load is an argument for owned hardware. Variable, seasonal, or unpredictably growing load is an argument for cloud.
Data requirements. Where must data physically reside? Are there regulatory restrictions on storing it abroad? How sensitive is access latency?
Horizon of the system's life. Three years or less - capital investment in hardware often does not pay back. Five years or more - the economics shift toward owned hosting.
Operational capability. Does the company have a team that knows how to run infrastructure? Or does support fall on one person?
Speed of launch. If you need to go live in three months, cloud is more realistic. If you can wait six months, this becomes a less decisive factor.
Mistakes I see most often
The decision is made at the company level instead of the system level. "We are moving to the cloud" as a policy is a mistake. Different systems have different answers.
Only capital costs or only operational costs are counted. The right calculation looks at total cost of ownership over the system's full lifetime - including people, migration, and support.
The cost of exit is ignored. Moving into the cloud has a switching cost. Leaving the cloud has one too. How hard it will be to change the decision in three years is a question that belongs in the initial analysis, not after signing.
A practical test
Before making a decision for a specific system, I recommend answering six questions:
- What is the expected load and how variable is it?
- What are the requirements for data location and sovereignty?
- What is the planning horizon for the system?
- What is the realistic cost over three years - hardware, people, and migration included?
- Do we have the operational competencies for the chosen option?
- How hard will it be to change course if we get it wrong?
If you answer these honestly, the choice becomes obvious in most cases.