Migration cost tracking is the discipline of measuring actual cloud spend against the migration business case throughout the move, not just at the end. It rests on three habits: tagging every migrated resource from the landing zone onward so cost is attributable from day one; tracking dual running cost, the period when you pay for both the old estate and the new, which is where most overruns hide; and naming an accountable owner for forecast versus actual, so variance has someone to explain it. Without these, a migration drifts because the people approving it never see the gap between what was promised and what is being spent until the invoices arrive.
Why migrations overrun the business case
A migration business case is a forecast made before anyone touched the new environment. It assumes clean lift, prompt decommissioning of the source, and rightsized targets. Reality intrudes: workloads land oversized because no one wants to risk a performance problem on cutover, the old data center keeps running because retiring it is someone else's quarter, and dual running drags on. None of this shows up until the cloud bill and the legacy invoice arrive together.
The fix is not a better forecast. It is tracking the actual against the forecast continuously, so drift is visible while you can still act on it, rather than discovered in a year end review when the money is already spent.
Tag from the landing zone, not after
Cost is only trackable if it is attributable, and attribution depends on tags applied before workloads move, not retrofitted afterward. Build the tagging policy into the landing zone so every migrated resource carries its application, owner, and migration wave from the first day it exists in the cloud. Retrofitting tags across a half migrated estate is painful and always leaves gaps that land in an unallocated bucket no one owns.
With tagging in place from the start, you can compare the realized cost of each migration wave against its slice of the business case, and you can see immediately which applications landed heavier than forecast.
Watch dual running, where overruns hide
The most underestimated cost in any migration is the overlap period when both the source and the target run at once. The business case usually assumes a short overlap. In practice, decommissioning the source slips because it carries risk and no glory, and every extra month of dual running is paying twice for the same capability.
Track dual running explicitly as its own line. Set a target decommission date per workload, report the workloads still running on both estates, and make the cost of the overlap visible to the people who can authorize the source shutdown. The discipline that ends a migration on budget is almost always the discipline of retiring the old estate on time.
Name an owner for forecast versus actual
Tracking only changes behavior when someone is accountable for the variance. Assign an owner for the migration forecast who reports actual against plan on a regular cadence and explains any gap. This is not blame, it is visibility: the owner is the person who can see a wave landing over budget and trigger rightsizing, renegotiation, or a faster decommission before the overrun compounds.
A Fortune 500 retailer migrating a large estate forecast a short dual running window and rightsized targets. Six months in, actual spend tracked well above the business case. Because every wave was tagged from the landing zone, the owner could see that two thirds of the gap was dual running on a data center that should have been retired, and the rest was oversized landing zone instances no one had revisited. Setting hard decommission dates and rightsizing the migrated workloads brought spend back toward the forecast. The lesson was not a better estimate, it was continuous tracking against the one already made. Figures are verified against billing data and anonymized.
A migration cost tracking checklist
Run these checks from the first wave to the final decommission.
| Control | Question | Why it matters |
|---|---|---|
| Tagging | Is every migrated resource tagged from the landing zone? | Cost is only trackable if it is attributable |
| Forecast vs actual | Is each wave reported against its business case slice? | Drift is only fixable while it is visible |
| Dual running | What is still running on both estates, and until when? | The overlap is where most overruns hide |
| Decommission | Does every workload have a hard source shutdown date? | Migrations end on budget when the old estate retires on time |
| Ownership | Who explains the variance each cycle? | Tracking only changes behavior when someone owns it |
Where tracking meets the wider estate
Migration economics connect to the broader question of where workloads belong. Once migrated, govern the estate as one in from cloud only to multi technology FinOps, weigh placement against when Oracle workloads belong on OCI, and design the target to cut cost using data architecture choices that cut the bill. The cross cloud frame is in the cloud cost optimization guide.
Frequently asked questions
Keep your migration on budget
We track migration spend against the business case in real time, expose dual running, and hold the forecast accountable so the move lands on plan rather than over it. Independent, buyer side, zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.