Cost & Budgeting
Cost & Budgeting3 min read
Why the cloud bill went up after the migration
Most migrations that disappoint on cost were priced as a move and delivered as a move. The savings come from the decisions people postpone.
Working on something like this?
Get an estimateThe short version
- Lift-and-shift moves the architecture as well as the servers, including its idle capacity.
- Non-production environments running around the clock are the most common single waste.
- Untagged spend is unmanageable spend: nobody optimizes a bill they cannot attribute.
- Fix sizing and scheduling before buying commitments — you cannot reserve your way out of waste.
A migration is sold on elasticity and delivered on capacity. The servers move, the architecture does not, and the organization ends up paying cloud prices for data-centre design. This is as true of an enterprise estate moving to Azure as of a single storefront.
That is not an argument against migrating. It is an argument for knowing which decisions actually produce the saving, and making them deliberately rather than hoping they arrive with the platform.
Where the money actually goes
The order to fix them in
1
Attribute before you optimize
Tagging and account structure first. A bill nobody can split by team or service will not be reduced by anyone, because responsibility is diffuse.
2
Turn off what nobody uses
Unattached volumes, idle load balancers, forgotten environments. This is unglamorous and usually the largest single reduction available.
3
Schedule non-production
Nights and weekends off for anything that is not production. It is a configuration change with immediate effect and near-zero risk.
4
Rightsize from data
Instance and database sizing against observed CPU, memory, and IO — not against what the equivalent server had on-premise. Fix the access pattern first, though: one retailer took 35% off the bill only after an uncached catalogue query was dealt with, and rightsizing around a broken one buys a cheaper version of the same architecture.
5
Only then commit
Savings plans and reserved capacity are a discount on what you use. Buying them before the previous four steps locks in your waste for a year.
What re-architecting actually buys
Moving from always-on instances to managed and serverless services is where the structural savings live — you stop paying for idle. It is also real engineering work, so it belongs on the workloads where the arithmetic supports it rather than as a programme-wide mandate.
- Good candidates: bursty, event-driven, or clearly seasonal workloads
- Poor candidates: steady high-utilization services, where always-on is already efficient
- Check first: heavy sustained serverless usage can cost more than a small always-on cluster
Budget for the migration itself
Two costs are routinely omitted from migration business cases: running both environments in parallel during the transition, and the egress charge for moving data out of wherever it currently lives. Neither is optional and both are forecastable.
If you want the delivery view rather than the cost view, our cloud solutions page covers how we assess, land, and migrate — and the combined cloud and DevOps engagement covers doing it alongside the delivery pipeline, which is what stops a migrated workload from still being deployed by hand.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
Almost always because the architecture moved unchanged. Servers sized for on-premise peak now bill continuously, non-production environments run around the clock, and data transfer that was free inside your own network is now metered. None of it is inherent to the cloud — it is the result of lifting a design built for fixed capacity into a model that charges for time.
It depends entirely on how much waste is present, which is why any firm quoting a percentage before looking at your bill is guessing. What we can say is where it is usually found: idle resources, unscheduled non-production, oversized instances, and storage nobody revisited. An audit against your actual usage gives you a real number rather than a marketing one.
After rightsizing, not before. Commitments discount what you actually use; buying them first locks in your current waste for one to three years and creates a disincentive to fix it. Get usage stable and correctly sized, then commit to the steady baseline.
Usually the opposite. You lose volume discounts, duplicate tooling and expertise, and add cross-cloud data transfer. There are good reasons for multi-cloud — regulatory requirements, acquisitions, specific services — but cost reduction is rarely one of them.