TCP #138: The rehost business case that was true in the slide deck
Three line items that turn a lift-and-shift savings story into a loss, and where each one hides until the first invoice.
The rehost business case got approved on a clean story:
Move the workload as‑is, shut down the data center, save money.
The slide compared on‑prem cost to modeled cloud cost. The savings number looked solid. Finance signed.
Six months after cutover, the finance review shows the cloud bill higher than the data center line it replaced.
The migration went exactly as planned. The savings did not.
Nobody lied. The model was just incomplete.
A “lift‑and‑shift” is not a single decision. It is three cost decisions dressed up as one migration choice.
Two of those three almost never get modeled before cutover.
Why This Is a Board‑Level Problem, Not an Engineering Detail
A rehost that costs more than the data center it replaced is not a rounding error. It is a credibility hit.
The program’s ROI story was built on this math:
Per‑workload savings × number of workloads = portfolio business case.
When the first big wave lands 30–40% over estimate, that gap doesn’t stay local to one app. It becomes the number finance repeats the next time you ask for migration budget.
And the bad news shows up late:
On‑prem: costs are sunk and mostly fixed. Overprovisioning hides in depreciation.
Cloud: costs are variable and visible. Overprovisioning is a monthly bill someone actually reads.
The same workload that quietly overspent in the data center now triggers a finance review every month, and each review re‑litigates whether the whole migration was a mistake.
Your migration program’s reputation is set by the first few invoices, not the last one.
Why the Estimate and the Invoice Don’t Match
The gap between model and reality almost always traces back to the same three line items.
1. Instance right‑sizing
Most teams size target instances to match provisioned capacity, not observed utilization.
On‑prem: server sized for a rare peak, used at 20–30% most of the year.
In cloud: lifted 1:1 to an instance that now bills every hour for that peak capacity.
In the data center, that waste was a sunk CAPEX decision no one revisited. In the cloud, it is an OPEX leak on every invoice.
2. Storage class drift
Lift‑and‑shift tooling defaults to “safe” storage tiers: GP2/GP3 volumes, standard [internal], general‑purpose everything.
Backups, logs, and archives land on the most expensive reasonable tier.
Nobody circles back to reclassify them because “optimize storage” loses to “migrate the next wave.”
Cold data keeps paying hot‑data rates indefinitely.
3. Data transfer that never existed as a line item before
On‑prem, traffic between app, DB, and dependencies rides the LAN for free.
In cloud, the same paths can cross:
AZ boundaries
Region boundaries
Out to the internet
Each with its own per‑GB charge that had no equivalent on the data center bill. It never showed up in the baseline, so it never made it into the model.
All three problems come from modeling what the workload is provisioned for instead of what it actually does.
The Three Questions That Catch This Before Cutover
Rehost is still the fastest, lowest‑risk way to move a big portfolio.
These three questions decide whether it’s also a cost win. They need answers before the business case is signed, not after the first invoice lands.
1. What does this workload actually use, not what is it provisioned for?
Pull real utilization:
CPU, memory, disk, IOPS
Over a window that includes representative peaks
Size instances to that pattern, with buffer, instead of mirroring the old server spec.
This single change closes most of the gap on most rehosts.
2. What is the access pattern for every dataset this workload touches?
Classify data by access:
Hot: request path, low‑latency, high‑frequency
Warm: regular but not critical
Cold: backups, logs, archives, legal holds
Each class has a different cost‑optimal storage tier. Your model should have per‑dataset storage assumptions, not one blended number.
Defaulting everything to a single “safe” tier is how storage quietly eats the savings.
3. What does this workload talk to, and where do those calls cross billable boundaries?
Map dependencies:
Databases, caches, downstream services, third‑party APIs
Which connections stay inside an AZ vs. cross-AZ / region / internet?
This is the line item that has no on‑prem analog, which is exactly why it’s the one most often skipped.
Once you see the paths, you can:
Co‑locate chatty services
Avoid unnecessary cross‑region calls
Decide consciously where to pay for egress
Answer these three and you’ve turned the “savings” slide from a wish into a forecast.
A forecast is the only thing finance should be signing off on.
What a Rehost Looks Like When the Math Holds
When you model these three line items up front, the rehost does what the slide deck promised.
Right‑sized instances mean you pay for actual consumption, not inherited overprovisioning.
Correct storage tiering means cold data costs cold‑data rates.
Pre‑mapped data transfer means you can design away the worst egress paths before they start billing.
The first finance review after cutover becomes validation, not a surprise.
And that changes the trajectory of the entire program:
Wave 1 shows invoices that match the model.
Wave 2 budget gets approved off evidence, not optimism.
The conversation shifts from “Can we trust these numbers?” to “How fast can we scale the factory?”
That is the real payoff: a migration program that can point at real bills and say, “The math holds.”
Free tool: Score your AWS platform’s predictability in 5 minutes
If this hit close to home, you probably have other places where ownership and accountability are fuzzy but invisible until something breaks.
To make this practical, I put together a free AWS Platform Predictability Starter Kit for readers:
5‑minute predictability checklist
“Where are we bleeding?” team scorecard
Platform risk radar with 12 early‑warning signals
10 executive questions with weak vs strong answers + debrief worksheet
Most leaders run through these in a week of normal meetings and come away with a clear “top 3” to fix next.
👉 Grab the free PDF here: https://thecloudplaybook.gumroad.com/l/aws-platform-predictability-check
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.