A migration finishes, everybody exhales, and a month later the first full invoice arrives. It is larger than the estimate. The one after that is larger again. Nobody did anything wrong, no service is misconfigured, and there is no single line item to point at. That is the normal shape of a post-migration cloud bill, and it is worth understanding why before anybody starts turning things off.
The short version: a lift and shift moves your hardware decisions into a place where they are billed by the hour, and most of those decisions were made for a world where that was free.
You Sized for Peak Because Peak Was Free
On-premise, you buy a server for the worst Tuesday of the year and for the next five years. Doubling the memory at purchase costs a few hundred dollars once. Getting it wrong costs a weekend of downtime and a purchase order. Every incentive points at buying too much, and so everybody does.
In the cloud, that same headroom is rented every hour, including nights, weekends, and the eleven months a year when the worst Tuesday is not happening. When the migration plan takes its instance sizes from the old spec sheet, and most do, you have not moved a workload. You have moved a purchasing decision that was correct under one set of rules into a place with completely different rules.
This is why right-sizing is the first move and not a later refinement. It is also why it cannot be done from a spreadsheet. You need two to four weeks of real CPU, memory, and disk throughput from the running workload, and then you size to observed load with a documented allowance for growth. Anything else is the spec sheet again with different numbers on it.
Cutting Cores Can Save More Than Cutting Cloud
Here is the part that surprises people. Database and ERP licensing is often priced per core or per vCPU. Take a right-sized server from sixteen vCPUs down to eight and you save the compute, which is real but modest. You may also halve a licence that costs several times the compute.
So run the licence maths as part of the sizing exercise, not after it. In more than one case the software cost is the reason to right-size and the infrastructure saving is the bonus.
Storage Only Ever Goes Up
Compute gets attention because it is the biggest number on the first invoice. Storage gets none, because each individual piece of it is small, and it is the line that grows on its own while everybody is looking elsewhere.
Three things drive it. Snapshots, taken as a safety net during the migration and then never expired, because nobody wants to be the person who deletes the one that was needed. Orphaned volumes, left behind when a test instance was deleted and its disk was not. And backup retention that was copied across from a tape rotation designed for a physical library with a fixed number of slots, which is not a constraint that exists anymore and therefore stopped being a limit on how much you keep.
The fix is unglamorous: a lifecycle policy per bucket and per snapshot class, a scheduled report of unattached volumes, and a retention schedule written against what you actually need to recover rather than against what the old hardware happened to hold.
Egress Is the Charge That Finds You Later
Data going in is usually free. Data coming out is not, and the workloads that generate it tend to be the ones added after the migration, when nobody is watching the bill as closely. A reporting tool pulling the full sales history every morning, a backup job writing to a different provider, a file share that a branch office reads across the internet all day, an image library serving a public site without a cache in front of it.
None of those look like infrastructure decisions when somebody sets them up. They look like a report, a backup, a share, and a website. The habit worth building is asking, of any new integration, which direction the bulk of the data moves and how often. That question takes ten seconds and it is the only one that catches this before the invoice does.
Nothing Turns Itself Off
Development, test, training, and the temporary copy of production that somebody made during the cutover and still has. On-premise those cost nothing incremental, so the habit of shutting them down never formed. In the cloud, an environment that is used during business hours and billed around the clock is paying for roughly three times the hours it is used.
A schedule that stops non-production instances at night and on weekends is close to free to set up and is usually the single largest percentage saving available. The objection is always that somebody might need it at odd hours, which is worth taking seriously exactly once: give them a self-service way to start it, then let the schedule run.
Do Not Commit Until You Have Right-Sized
Reserved capacity and savings plans are real discounts, and the sales conversation about them tends to arrive early, because a one-year or three-year commitment is good for everyone selling it. Sign one before right-sizing and you have bought a discount on the wrong shape, and locked yourself out of the larger saving for the length of the term.
The order matters more than any individual step. Measure, right-size, remove what is not running, schedule what does not need to run continuously, and only then commit to the steady-state footprint you are left with. Reversing the last two steps is the most expensive mistake available in this whole exercise, and it is the one most often made, because committing feels like taking action and measuring feels like delay.
What Makes the Saving Stay Saved
Every cost cleanup works. Most of them come undone within a year, because the conditions that created the original bill are still in place: resources get created quickly, by several people, with no record of who owns them or why.
Two things hold the gains. First, a tag on every resource naming an owner and a purpose, enforced at creation rather than audited later. An untagged resource is one nobody will ever be willing to delete, because nobody can prove it is safe to. Second, a short monthly review of the bill by service, looking at the shape of the change rather than the total. A total tells you the bill went up. Service-level movement tells you which decision made it go up, while the person who made that decision still remembers making it.
The goal is not the smallest possible bill. It is a bill you can explain, where every line traces to something the business decided to run.
Uptimize Solutions plans and runs infrastructure for manufacturers and distributors, on-premise and in the cloud. If your cloud bill has stopped matching the plan, see our infrastructure services or book a free workflow audit.