senn-techOn-Premise vs. Cloud: The Bill Nobody Wants to Pay
The cloud debate is rarely based on calculations; it’s mostly a matter of belief. One side says everything belongs in the cloud because hardware is a thing of the past. The other says the cloud is expensive and insecure. Both sides are right in certain cases, and that’s exactly why a blanket answer is always wrong.
We do both—we run our own cluster for everything with a constant load and use rented capacity for everything else. Here’s the breakdown of our costs.
The Three Factors That Matter
1. How consistent is the load? An inventory management system, a file server, and a database run around the clock with similar demand. For something like this, you’re constantly paying for elasticity in the cloud that you never actually use. Conversely, for a web store with holiday sales, a test environment, or a rendering job—that’s exactly where this elasticity is the whole point.
2. How much capital can be tied up? Owning your own hardware is an investment that depreciates over four to five years. For a business that needs every euro in its working capital, this is the decisive factor—and a completely legitimate reason to move to the cloud, even if the five-year financial projection suggests otherwise.
3. Who runs the operation? This is the item that’s miscalculated on both sides. On-premises hardware requires people to install updates, analyze monitoring data, and be available at night. The cloud requires people to monitor costs, manage permissions, and understand what you’re being billed for.
What’s Missing from the On-Premises Calculation
| Item | Usually Included | Usually Overlooked |
|---|---|---|
| Servers, storage, network | ✓ | |
| Power and cooling | ✓ | |
| Maintenance contract | ✓ | |
| Labor hours for operations | ✗ | |
| Spare parts and replacement equipment | ✗ | |
| Second location for disaster recovery | ✗ | |
| Off-site backup destination | ✗ |
The largest of these items is labor time. Anyone who assumes that a colleague will “handle this on the side” for ten virtual machines isn’t factoring in half a day per week—which, over five years, adds up to more than the cost of the hardware.
What’s Missing from the Cloud Calculation
| Item | Usually Included | Usually Overlooked |
|---|---|---|
| Computing power and storage | ✓ | |
| Licenses | ✓ | |
| Outgoing data traffic | ✗ | |
| Costs of leaving the provider | ✗ | |
| Backup within the same provider | ✗ | |
| Cost monitoring as an ongoing task | ✗ |
Outgoing data traffic is the classic example. Uploading data is cheap or free. Retrieving it costs money—and specifically when you want to switch providers. Retrieving several terabytes can cost a four-digit amount before a single line of data has even been migrated.
The second issue is backup. A backup within the same account at the same provider protects against a deleted directory, not against a compromised account.
Where the Tipping Point Lies
As a rule of thumb based on real-world experience: With a constant baseline load over more than three years, on-premises hardware almost always wins the pure cost analysis—often by a wide margin. With fluctuating loads, short runtimes, or limited capital, the cloud wins.
The tipping point usually lies between the second and fourth years of operation. This is also why migrations occur in both directions and both sides can tell success stories: they’re looking at different time frames.
The Third Answer
For most medium-sized businesses, neither option is the right one; rather, the solution lies in a mix:
- On-premises: inventory management, databases, file storage—everything with a constant workload and sensitive data.
- Off-premises: test environments, peak workloads, the second backup copy, public websites.
This provides cost control where the load is predictable and flexibility where it isn’t. And it fulfills the 3-2-1 rule for backups as a side benefit, since the second copy is located off-site anyway.
When moving to the cloud, choosing a provider is no minor detail: A European provider avoids the debate over data transfers to third countries, and open-source software running on rented hardware preserves the option to switch back—a flexibility that a proprietary platform doesn’t offer.
What You Should Do Before Making a Decision
- Measure the actual load. Not the peak figures from the spec sheet, but what actually accumulates over four weeks.
- Calculate over five years. A three-year calculation systematically favors the cloud, while a ten-year calculation systematically favors your own hardware.
- Factor in labor costs. On both sides, using a realistic hourly rate.
- Check the exit strategy. What will it cost to move back in three years? If the answer is unpleasant, that’s an argument against the option—not just a detail.
Further Reading
Is the cloud more expensive than having your own hardware?+
With a constant base load over several years, this is almost always the case; with a fluctuating load, it is almost never the case. The tipping point usually lies between the second and fourth year of operation. Three factors are decisive: how constant the load is, how much capital can be tied up, and how much operational work is performed in-house.
Which cost category is often overlooked in on-premises setups?+
Labor costs. Hardware, electricity, and maintenance contracts are included in every invoice, but the hours spent on updates, monitoring, troubleshooting, and backup tests are almost never included. For small environments, this item is often larger than the depreciation expense.
Which cost category is often overlooked when it comes to the cloud?+
Outbound data traffic and the cost of retrieving data. Uploading data is cheap or free, but retrieving it is not. Anyone who wants to retrieve several terabytes after three years will pay a four-digit amount just for the transfer.
What about a mix?+
For most companies, this is the right solution: in-house production and data with a constant workload, test environments, peak workloads, and a second backup copy off-site. This provides cost control where the workload is predictable and elasticity where it isn't.