The cloud doesn't save you money — your strategy does

Every cloud migration business case starts with a beautiful TCO comparison. On-prem hardware, facilities, and licensing costs on one side. A sleek AWS monthly bill on the other. The math checks out. Leadership signs off. And then, two years in, the CFO starts asking uncomfortable questions.

I’ve seen this play out at dozens of enterprises. The cloud can save you money — significantly. But not because of some inherent magic in pay-as-you-go pricing. It saves you money because of two very specific things you do after you migrate. Miss either one, and you’ll end up spending more than you did before.

The two levers that actually matter

Lever 1: shut down what you left behind

This sounds obvious. It isn’t.

Moving workloads to AWS while continuing to pay for the data center they came from is not a migration — it’s a duplication. Yet this is exactly what happens when organizations treat migration as a technical project instead of a financial one. Servers get re-hosted in the cloud, but the old environment stays warm “just in case.” Contracts auto-renew because nobody flagged the termination window. The facilities team keeps the lights on because three remaining workloads haven’t moved yet.

The first lever of cloud savings is decommissioning. Not migrating to the cloud — migrating away from the data center. The savings show up when you power down racks, terminate support contracts, and exit co-location agreements. If you can’t draw a straight line from a migrated workload to a specific cost line item that disappears, you haven’t saved anything.

Lever 2: adopt what the cloud actually offers

The second lever is more nuanced: using cloud-native capabilities to run your infrastructure differently. A managed database means nobody gets paged at 3am for a failover. Auto-scaling means you stop buying for peak and hoping you guessed right. Serverless means you pay nothing when nobody’s using the thing.

But here’s where I’ll be more direct than most: managed services are not universally cheaper. An RDS Multi-AZ deployment for a stable, well-understood database workload might cost more than running it yourself on EC2 — especially if your team already has deep MySQL or PostgreSQL expertise. A NAT Gateway will quietly drain your budget if you have high data throughput. AWS Client VPN at scale can be eye-wateringly expensive compared to a self-hosted alternative.

The question is never “should we use managed services?” It’s “where does the trade-off between operational overhead and cost actually tip?” That depends on your team’s skills, the workload itself, and how much undifferentiated ops work you’re willing to carry. Use managed services where they make your life simpler. Skip them when a slide deck is the only reason they’re in the architecture.

Speed matters — but so does timing

AWS recommends completing migrations within a year, and they’re right. Migrations that stretch to two or three years lose steam. The team that started the project moves on, requirements change underneath you, and the organization never fully commits to operating in the cloud. What you get is the worst of both worlds — paying for AWS and keeping the old environment alive indefinitely.

But — and this is the nuance that matters — “move fast” doesn’t mean “start today.”

How much this matters depends on your scale. A large enterprise running thousands of workloads across multiple data centers can’t afford to wait for every contract to expire — that would take a decade. At that scale, you’re better off absorbing a few months of double cost and getting to the other side. Shutting down a large data center saves serious money, and those savings start the day the last rack powers off.

For a mid-sized company with a manageable footprint — a few racks in a co-location facility, a handful of software contracts, a hardware refresh cycle you can see end-to-end — the calculus is different. Migrating everything to AWS while you still have 18 months on your co-lo lease and two years on a recently purchased hardware stack means paying double for a long time. At this scale, the smarter move isn’t a detailed multi-year plan. It’s picking the right moment to start — and then moving decisively.

Start at the right time — then move in smart waves

The idea that you need a carefully phased three-year migration roadmap is, in most cases, overthought. But so is the idea that you just flip a switch and move everything at once. The reality is a balance: pick the right moment to start, then sequence your migration in waves that respect both financial and technical realities.

The starting point matters. You don’t begin a migration 18 months before your data center lease expires and then take two years to finish. You identify the moment when your major commitments start converging — hardware approaching end-of-life, software contracts entering their renewal windows, a co-location agreement coming up for renegotiation — and that’s when you pull the trigger. Not six months before in a planning phase, not a year after because the steering committee couldn’t align.

But once you start, you’re not migrating everything in a single weekend. You’re running waves, and each wave has to balance several things at once. Technical dependencies set the order — you can’t move an application before the database it talks to, and a shared service stays put until every consumer has migrated off it. Financial timing decides what goes first: workloads on fully depreciated hardware or expiring contracts are the obvious early movers, because decommissioning them frees up real budget immediately. Workloads on recently renewed contracts or fresh hardware? Park them in a later wave. Moving them early just means paying twice. And then there’s team capacity — even an aggressive timeline has to stay within what your people can actually deliver without cutting corners that turn into technical debt six months later.

An AWS MAP deal gives you a three-year funding vehicle, but that’s not a migration timeline. The migration itself should land within the first year. Years two and three are for optimization — right-sizing instances, moving to cloud-native services where they make sense, buying Savings Plans based on actual usage data, and building out your FinOps practice. The MAP runway gives you room to get the economics right after you’ve already made the move.

This approach requires honesty about where you are today. You need a clear picture of what contracts lock you in and until when, which hardware still has useful life, how your applications depend on each other, and what your team can realistically execute in a quarter. Those answers — not a Gantt chart — are what shape your migration.

The honest conversation

At AllCloud, we have these conversations regularly. And the companies that end up with real savings are almost always the ones that treated migration as a financial decision first and a technical project second.

That means sometimes telling a client to wait. Their hardware is new, their contracts are locked in for two more years, and migrating now would mean paying double with no clear upside. Come back in 18 months and we’ll move fast.

And sometimes it means telling a client to move now. Their data center lease is up in 10 months, their hardware is aging, and every month of delay is a month of unnecessary cost. Stop planning. Start migrating.

The technology is the easy part. Getting the timing right, having the discipline to say “not yet” when the numbers don’t work, and then moving with real urgency when they do — that’s what separates a migration that pays for itself from one that just adds a second bill.

If you’re evaluating a move to AWS, start with the financial picture, not the architecture diagram. The architecture will follow.