Every cloud migration I have ever seen has two budgets: the one in the business case, and the real one. The gap between them is where careers get uncomfortable. It is rarely caused by one big mistake. It is caused by a dozen small leaks that nobody owned — over-provisioned instances, architectures chosen for speed instead of cost, license traps, and the quiet sprawl of resources nobody remembers spinning up.
I have spent 10 years at a global cloud provider working on massive application and data migrations, and I have led migration programs from both sides of the table. This post is about where migration money actually goes, and how to keep control of it.
Where Migration Budgets Actually Leak
Let me walk through the leaks I see most often, roughly in order of how much damage they do.
Lift-and-shift waste. The fastest way to migrate is to move workloads as-is. It is also the most expensive way to run them. An on-premises server sized for peak-plus-headroom becomes a cloud instance billed by the hour at that same generous size — except now the headroom costs real money every month, forever. Lift-and-shift is a valid migration strategy; it is a terrible operating strategy. The mistake is treating the migration as finished at cutover instead of as step one of optimization.
Over-provisioning by default. Engineers size for safety. Without cost feedback, “safe” means the next size up. Multiply that instinct across hundreds of workloads and you are paying a meaningful premium for comfort. I have seen estates where the majority of instances averaged a small fraction of their provisioned capacity. That gap is pure waste, and it is invisible until someone measures it.
Idle and forgotten resources. Dev and test environments that never shut down. Proof-of-concept infrastructure from a project that ended two years ago. Snapshots nobody will ever restore. Storage volumes detached from deleted instances, billing quietly in the background. At enterprise scale, this category alone can fund a team.
Data transfer. Everyone models compute and storage. Far fewer model data transfer — between regions, between availability zones, and out to the internet. For data-heavy workloads, transfer costs can rival compute. Architecture decisions made without transfer pricing in mind (chatty cross-region replication, for example) create bills that surprise everyone.
The long tail of “temporary.” Migration tooling, jump hosts, temporary databases for validation, dual-running old and new environments “just until we’re sure.” Each is justified individually. Collectively, they extend the period where you are paying for two estates instead of one. The old estate must have a decommission date, or “temporary” becomes permanent.
Architecture Decisions Are Cost Decisions
Here is the uncomfortable truth: by the time the FinOps team sees the bill, the costs were already decided — months earlier, in architecture reviews where nobody asked about money. Cost is not a billing problem. It is a design problem.
Every major architecture choice has a cost dimension. Managed database services versus self-managed on compute instances: the managed service looks more expensive per hour until you count the engineering time, the patching, the failover testing, and the 3 AM pages. Sometimes self-managed wins; sometimes it loses badly. The point is that the comparison has to happen before the decision, not after the invoice.
Compute architecture is one of the biggest levers available. I have led complete migrations from traditional x86-based estates to ARM-based processor architectures — the kind of fleet-wide architecture change that sounds terrifying and turns out to be methodical work: assess workload compatibility, migrate in waves, validate performance at each step. The economics are compelling because processor choice affects every workload, every hour. It is the rare optimization that compounds across the entire estate instead of applying to one application.
Storage tiering is another. Production databases on high-performance storage, fine — but backups, logs, and infrequently accessed data on the same tier is money left on the table. Lifecycle policies that move data to cheaper tiers automatically are the difference between a policy and a wish.
The principle: put a cost line on every architecture decision document. Not a precise forecast — a directional one. “This choice costs roughly X relative to the alternative, because Y.” It takes ten minutes and changes the conversation permanently.
The License Trap
Licensing deserves its own section because it ruins more migration business cases than any technical issue.
Enterprise software licensed per core, per processor, or per user was priced for a world of fixed on-premises hardware. In the cloud, where cores are elastic and instances come and go, the old licensing math breaks — usually against you. I have seen organizations discover mid-migration that their database licenses, perfectly economical on owned hardware, became punitive when mapped to cloud instance sizing.
The traps to watch: licenses that don’t transfer to the cloud the way you assumed (read the actual terms, not the sales deck); “license-included” managed services that look expensive until you price the alternative honestly; and the worst one — migrating first and doing license analysis second, when your negotiating leverage is gone.
Do the license analysis during the assessment phase, workload by workload. For each one, the question is simple: what does this license cost here versus there, including every alternative (bring-your-own-license, license-included services, open-source substitution, rearchitecting away from the licensed product)? This analysis has saved programs I have worked on from genuinely painful surprises. It is unglamorous work. Do it anyway.
Building Cost Accountability Into the Program
Knowing where money leaks is not enough. Someone has to own stopping the leaks, continuously. That is what a working FinOps practice looks like inside a migration program — not a dashboard, but accountability.
Tag everything, enforce it technically. A tagging policy that lives in a wiki is decoration. Enforcement means provisioning fails when required tags are missing. A minimal starting point:
{
"required_tags": ["owner", "cost-center", "migration-wave", "environment"],
"enforcement": "deny-provisioning-if-missing",
"review_cadence": "weekly"
}Four tags. With them, you can answer “who spent what on which wave” — without them, you are guessing.
Review cost per migration wave. Don’t wait for quarterly business reviews. After each wave of workloads migrates, review its actual cost against the estimate within weeks. Variances found early are corrections; variances found at year-end are explanations.
Showback before chargeback. Start by showing teams what they spend. Most engineers have never seen the bill for their architecture choices, and the first time they do, behavior changes without any mandate. Chargeback (actually billing internal teams) is stronger medicine — use it where showback doesn’t move the needle.
Assign a cost owner per workstream. Not a committee. A named person whose job includes the cost outcome of their migration wave, with cost as an explicit success criterion alongside timeline and functionality. What gets owned gets managed.
Right-size on a schedule, not on courage. Build a recurring right-sizing review into the operating model — monthly for the first six months post-migration, quarterly after. Right-sizing is not a one-time event; workloads change, and the estate drifts back toward waste without it.
Don’t Buy Discounts Before You Know Your Shape
One more lever deserves attention because the timing matters: committed-use discounts and reserved capacity. Cloud providers will sell you significant discounts in exchange for committing to a level of usage — and for stable, well-understood workloads, this is straightforward savings.
The trap is committing too early. Teams fresh off a migration, still running oversized lift-and-shift instances, lock in discounts on a footprint they haven’t optimized yet — and then spend the next one to three years getting a great price on waste. The right sequence is: migrate, optimize (right-size, tier storage, kill the idle), then commit on the stable remainder. The discount applies to whatever you commit to, so make sure you’re committing to the efficient version of your estate, not the just-migrated version.
Related: savings plans and reservations are a finance decision as much as a technical one. They need someone tracking utilization of the commitment itself — an underutilized reservation is just waste with a discount label. Review commitment coverage quarterly, same cadence as right-sizing. The two practices belong together.
What Good Looks Like
A migration program with cost under control doesn’t look dramatic. It looks boring: estimates that hold, waves that land near their cost targets, a decommissioned old estate, and a FinOps review that takes thirty minutes because there are no surprises.
Getting there requires treating cost as a first-class migration metric from day one — alongside timeline, scope, and risk. It requires architecture reviews that ask about money. And it requires the discipline to optimize after cutover instead of declaring victory and moving on.
The organizations that do this well share one trait: someone senior decided that the migration’s success would be measured in part by its economics, and said so out loud, early. Everything else — the tagging, the wave reviews, the right-sizing — follows from that decision.
The Bottom Line
Cloud migration costs are controllable, but only if cost is designed in, not bolted on. Audit your licenses before you migrate, put cost on every architecture decision, enforce tagging technically, review each wave’s spend while you can still correct it, and never let “temporary” infrastructure become permanent.
If your migration budget is leaking — or you’re planning a migration and want the business case to survive contact with reality — reach out through the contact page. This is the part of migrations I’ve spent years getting right, and I’m glad to help you think through yours.
Related: case studies, including a fleet-wide compute cost migration.
Thanks for the comment, will get back to you soon… Jugal Shah