Cloud or on-premise: the five costs the comparison always leaves out
The comparison is usually hardware price against monthly subscription. Five costs are missing from it, in both directions, and three cases where staying on your own hardware holds up.
By Laurent TulpanPublished 9 min read
The discussion nearly always runs the same way. On one side the price of a server, amortized over five years. On the other a monthly subscription, multiplied by sixty. The second looks more expensive, the decision is taken, and the calculation was incomplete.
Here are the items missing from it, in both directions, because cloud has its own hidden costs.
The five missing items
One. Replacing the hardware. A server is replaced every four to six years, and not at the price paid the first time, because the replacement usually drags other changes with it. A five-year calculation that does not provision for renewal is comparing a continuing subscription against a one-off purchase, which makes no sense.
Two. Power and cooling. A server draws continuously and heats a room that must then be cooled. On one machine this is not decisive; on several it becomes a real line that never appears in the comparison because it is buried in the general utility bill.
Three. The human time of running it. Patching, monitoring, checking backups, replacing a failed disk. That time exists whether or not anybody counts it, and when nobody counts it, that is often because it is not being done: patches fall behind, backups go unverified. In an organization without dedicated staff, this is the item that decides the outcome, and it is rarely one person’s spare capacity for long.
Four. What an outage costs with no spare part. This is the heaviest and the most invisible item. If a power supply fails and has to be ordered, the delivery time becomes your recovery time. The question is not the probability of the failure, it is what three days of downtime costs, and nobody has established that in advance.
Five. On the cloud side, egress and the services around the edges. The headline rate covers compute and storage. Data transfer out, backups, static addresses, load balancing are frequently billed separately. A cloud invoice that doubles in the second month is almost always an invoice where only the first line was read.
What each option actually buys
Cloud buys transferred risk. Hardware stops being your problem, replacing a failed disk stops concerning you, and hardware failure becomes the business of someone whose job it is and who is contractually accountable for it. It also buys elasticity, which is only worth something if your load genuinely varies.
On-premise buys control and predictability. The cost is known in advance, the data are physically with you, and nothing depends on a vendor’s pricing decisions. It also buys independence from your internet connection, which is not trivial for a workshop or a warehouse.
Put differently: cloud converts a risk into a monthly expense. On-premise converts an expense into an accepted risk. Both are legitimate choices. What is not legitimate is believing you avoid the risk by avoiding the expense.
The three cases where staying on your own hardware holds up
An explicit regulatory or contractual constraint on where data may live. This is worth verifying rather than assuming: many organizations believe they are constrained and are not, and the reverse happens too.
Large, low-mobility data volumes. Some work involves heavy files continuously: imaging, drawings, video. Moving that through an internet connection costs working time and egress fees, and the comparison changes completely.
An operation that must work without internet. A production line that stops when connectivity drops has a good reason to keep locally whatever drives production. That is not distrust of cloud, it is an availability calculation.
One case that is not a case: we already invested in the server. That money is spent, it is equally spent whichever way the next decision goes, and letting it into the comparison leads to keeping a situation purely because you are already in it.
The subject that actually decides, and it is not hosting
On the assessments we run, the cloud-or-on-premise question almost always arrives in a context where the restore has never been tested.
That is the most important fact in the conversation. A modern infrastructure whose data you cannot recover is more dangerous than a dated one whose data you can. And moving a system to the cloud does not improve backups: the tooling knew the old platform, not the new one, and the chain has to be requalified. A successful migration whose backups no longer work is an incident that has not happened yet.
If a vendor proposes a migration without a line for requalifying and testing the restore on the new platform, that omission tells you what the rest of the proposal is worth.
Four questions to ask a host before signing
What is the recovery commitment, not the response commitment? Knowing that somebody has opened a ticket restores nothing.
Where do the data reside, legally and physically? Two different answers, and the first governs your obligations.
What happens if I want to leave? In what format the data come out, how long it takes, at what cost. A host without a precise answer has told you something, and it is the same logic as for any vendor: the exit is negotiated before you need it.
What is included in the rate, and what is billed on top? Asked the other way round from habit: it is the exclusions that explain the gap between two offers.
Further reading
- Leaving VMware: the state of the market, and how to migrate safely
- Your backups run. Do they restore?: to verify before moving anything
- Modernize or renegotiate: pricing the exit before deciding
- The exit clause you negotiate before you need it: what makes a hosting contract renegotiable
- Legacy modernization: how we run this kind of move
The questions this raises, answered straight.
Is cloud cheaper than buying servers?
On the visible invoice, often not. On the complete cost, often yes, and the gap comes from items the usual calculation omits: replacing hardware every four to six years, power and cooling, the human time of running it, and above all what an outage costs when there is no spare part on the shelf.
A purchased server looks cheaper because part of its cost is paid in time and risk rather than in dollars.
Are our data less protected in the cloud?
Not inherently, and often the reverse in practice. A professional host patches, monitors access and replicates data more consistently than most small server rooms.
The real question is not the security of the location, it is control: who holds the keys, where the data legally resides, and what you can retrieve if you leave. All three have contractual answers, and they are worth settling before signature.
What happens if our internet connection goes down?
That is the most serious objection to cloud and it deserves to be costed rather than dismissed. In the cloud, losing connectivity stops everything that depends on it, whereas a local server keeps serving the internal network.
The answer is not ideological: either a second connection from a different carrier, or keep locally whatever has to survive an outage. The question to answer is what an hour without access costs you.
Can we do both?
Yes, and it is common when the decision is made properly. Large or heavily constrained data stay on site, the rest goes to a host. What makes the hybrid work is knowing who backs up what, and having written it down: a mixed setup where backup responsibility is ambiguous is the worst of both.
Recognize your situation? 20 minutes is enough to tell.
Describe what is happening on your side, and where your data and customers are. You get a plain answer on whether we can help, and a better route if there is one.