Blog / hosting
Does Moving Off the Cloud Actually Save Money?
Cloud repatriation gets pitched as an easy win. Here is how I work out whether moving workloads onto your own servers saves a company anything real.
Every couple of years a post goes around about a company that moved off the public cloud and cut its bill by seventy percent. The post is usually honest. The problem is that it describes one workload, at one company, with one team, and it gets read as a general rule.
I spent about fifteen years inside hosting companies watching traffic move in both directions. Some of it moved because the numbers genuinely worked. Quite a lot of it moved because somebody had a bad month with a bill and wanted to feel decisive.
So when a team asks me whether they should pull workloads back onto their own servers, I do not answer the question directly. I make them break the bill apart first.
Split the bill before you argue about it
Most cloud invoices are four or five different purchases stapled together, and they behave differently.
There is raw compute, which is the part people fixate on and the part that is easiest to replace. There is storage, which is usually cheaper than people think until they look at what they are paying for snapshots and old backups nobody has ever restored. There is data transfer out, which is often the single line that makes repatriation attractive. Then there are the managed services: the database you do not administer, the queue, the object store, the identity layer, the load balancers that fail over without anyone waking up.
That last category is the one that decides the answer. If most of your spend is compute and egress, a move is a real conversation. If half your spend is managed services, you are not moving servers, you are proposing to rebuild and then operate those services yourself, with your own people, forever.
That is a hiring decision dressed up as an infrastructure decision.
The line that never appears in the comparison spreadsheet
Almost every repatriation estimate I get handed compares a monthly cloud bill against the monthly cost of dedicated hardware. It comes out looking great, because the second number is missing most of its contents.
Hardware has a lifecycle. Drives fail, usually in the least convenient rack. You need spares, or a vendor with a four-hour replacement window, and you need someone who will drive to the facility or pay for remote hands. You need a patching cadence, and someone who owns it when a kernel update goes badly at 11pm on a Sunday.
Then there is redundancy. A single dedicated box is not equivalent to a managed service with automatic failover, and pretending otherwise is how a cheap plan becomes an outage. If you want the same availability, you buy the second machine, the second site, and the tested failover procedure.
Add a realistic slice of a salaried person's time and a lot of these comparisons narrow to something unexciting. Not always. But often enough that I insist on the line being there.
Where the move usually does pay off
There is a fairly consistent shape to the cases that work.
Load is steady and predictable, so you are not paying for elasticity you never use. Egress is heavy, which is the cost cloud providers are least forgiving about. Storage is large, boring and slow-changing. The team already runs servers competently for something else, so the operational skill is not a new purchase. And the workload has been stable long enough that you can forecast the next two or three years without guessing.
Video, large file delivery, backup targets, batch processing and long-running internal systems all tend to fit. So do mature products whose architecture stopped moving a while ago.
Where it usually does not
Spiky or seasonal traffic, where the whole point of the platform is that you stop paying when nobody is using it.
Small teams, where one person leaving takes the operational knowledge with them.
Anything still changing shape weekly, because you will spend your savings on rework.
And companies whose compliance posture leans on their provider's certifications. You can meet those obligations on your own hardware, but it is work, and it should be priced before the move, not discovered during an audit.
The version that tends to work
The teams that get a good outcome rarely do this as one dramatic migration. They move the boring, steady part of the platform first and leave everything spiky or stateful where it is. They keep one foot in each camp on purpose, accept the small tax of running two environments, and stop once the savings flatten out.
That is less satisfying than a clean break, and it works far more often. If you do go ahead, the ordinary migration risks still apply, and I have written before about how migrations actually go wrong. The failure is almost never the servers.
How to test the decision in an afternoon
Pull twelve months of billing and tag every line to a workload rather than a service. Price the steady baseline against dedicated hardware, including the second machine. Add a loaded cost for whoever will carry the pager. Work out what it costs to reverse the decision in two years, because sometimes that number is the whole answer. Then set a date to review it instead of treating it as permanent.
If your baseline is fuzzy, the real problem is measurement, not platform, and capacity planning is the piece to fix first.
I do this kind of review as a fixed-fee engagement, and I do not resell hosting or take vendor commissions, so the answer is sometimes that your current setup is fine. If you want the numbers checked by someone with no stake in the outcome, get in touch or have a look at how I work with hosting and platform teams. For companies that would rather hand the whole thing off, my hosting company DrivenHost runs managed infrastructure, but that is a separate conversation from this one.