Five questions that decide cloud or on-premises for one workload
Pick one workload. Not the estate — one system, with a name. Answer these five about it, and the answer usually falls out before you reach the end.
How does this workload's demand change over time?
Flat demand favours owning. Spiky demand favours renting.
A payroll system that runs the same load every day of the year has no use for elasticity, and you would be paying a premium for a capability it never uses. A retail website that does a third of its year in six weeks has exactly the opposite problem: buy for the peak and it sits idle for ten months.
The question that settles it: what is the ratio between this workload's busiest hour and its quietest? If the answer is close to one, owning is competitive. If it is ten, renting almost always wins.
Environments that exist temporarily — development, test, training, a migration rehearsal — are the clearest cloud case there is, because you pay only while they exist.
Where does the data have to live, and who may see it?
This one is not a cost question and it is not negotiable, so ask it early. Some data has a legal or contractual home. A regulator, a customer contract or a national rule says it stays in a country, a jurisdiction or a building.
If that applies, it decides the answer on its own — either on-premises, or a cloud region that meets the requirement with the paperwork to prove it. Everything else in this page is secondary to that.
Where it does not apply, and for most workloads it does not, move on.
How much data moves in and out, and how often?
This is the question nobody asks until the bill arrives.
Cloud providers charge little to put data in and meaningfully more to take it out. A workload that ingests a lot and emits little is comfortable. A workload that continuously pushes large volumes out — video, backups to another provider, analytics feeding external systems — pays that charge every month, forever.
Data gravity is the companion problem: the more data sits somewhere, the more the processing wants to sit beside it. If your analytics data is already in the cloud, running the analysis anywhere else means paying to move it every time. That is a strong argument for keeping analytics workloads where the data already lives, and it is the point at which data analytics design and infrastructure design stop being separate conversations.
How fast does this workload need to change?
Some systems are rewritten every sprint. Others have not changed in four years and should not.
Fast-changing workloads benefit from the cloud beyond raw capacity: new services available immediately, environments spun up per branch, a rollback that takes seconds. Slow-changing workloads get little from this, and a stable system on owned hardware is one of the cheapest things a business can run.
There is a second-order effect worth naming. Fast-changing workloads accumulate dependencies on the platform they run on. That is fine, and it is also how a cloud workload becomes expensive to move later.
What happens to the business when it is down?
Resilience is buyable in both places and it is never free in either.
In the cloud, running across regions is a design choice with a price attached, and the default is not resilient — a single region is a single point of failure. On-premises, a second site is a second set of hardware, a second room and a link between them.
So the question is not which is more reliable. It is how much downtime this workload can take, what you are willing to spend on disaster recovery to shorten it, and whether anybody has tested the failover.
Where continuous monitoring is part of the answer, our note on a network operations centre covers what that costs to staff.
Applying the five questions to one workload this week
Take the system that prompted the question. Write its name at the top of a page and answer the five underneath, in a sentence each.
Most workloads resolve on one answer. Data residency decides it outright. A ten-to-one demand ratio decides it. Heavy continuous egress decides it. If two answers point in opposite directions — spiky demand and a residency rule, say — that is what hybrid is for, and the section below covers the shape it should take.
If all five answers are mild, the workload is genuinely either, and the tiebreaker is usually when the hardware it currently runs on is next due for replacement.
