The migration decision framework scores every workload on three axes, total cost of ownership over a multi year horizon, the risk and effort of moving it, and timing against datacenter and contract deadlines, then assigns one of four outcomes: lift and shift, modernize, repatriate, or stay. The discipline that saves money is refusing a single blanket answer. In a real estate, some workloads should move as is for speed, some should be refactored to capture cloud native economics, some should never have left owned infrastructure, and some should stay exactly where they are. The framework forces that distinction instead of paying for a one size decision.
This article sits in the migration and repatriation economics cluster and links up to the cross cloud cloud cost optimization guide. Provider names are AWS, Azure, GCP, and OCI throughout.
What are the three scoring axes?
Total cost of ownership. Model the workload's cost over a multi year horizon on each option, not the first month. Cloud TCO includes compute, storage, data transfer and egress, and the commitment discounts you can defensibly cover, Savings Plans, Reservations, CUDs, or Universal Credits. Owned infrastructure TCO includes hardware refresh, facilities, and staff. The honest comparison is steady state cloud cost after optimization against fully loaded owned cost, not list cloud price against a sunk asset.
Risk and effort. How hard is the workload to move, and what breaks if it goes wrong? A stateless service is low risk; a tightly coupled database with licensing entanglements is not. Effort to refactor is a real cost that has to clear the TCO benefit before modernization is the answer.
Timing. Deadlines change the math and the leverage. A datacenter lease expiry or a hardware refresh forces a decision window; a credible deadline you control is negotiation leverage with providers on migration funding and commitment terms.
What are the four outcomes?
| Outcome | When it wins | Cost note |
|---|---|---|
| Lift and shift | Deadline pressure, low refactor value, acceptable cloud TCO | Fast, but leaves cloud native savings on the table until a later optimization pass |
| Modernize | Refactor benefit clears the effort cost over the horizon | Captures cloud native economics, managed services, autoscaling, but costs engineering time up front |
| Repatriate | Steady state cloud cost exceeds fully loaded owned cost | Right answer for stable, predictable, high volume workloads where cloud elasticity adds no value |
| Stay | Move does not pay, or risk outweighs benefit | A deliberate no is a valid, money saving decision |
The same estate routinely produces all four. Forcing every workload onto one path is the error the framework exists to prevent.
How do you run the framework?
Work the estate in three passes. First, inventory and group workloads by archetype, stateless service, database, batch job, legacy monolith, so you score families rather than thousands of items. Second, score each archetype on the three axes with real numbers: model TCO on the destination after realistic optimization, estimate refactor effort honestly, and map deadlines. Third, assign the outcome and sequence it, deadline driven workloads first, high benefit modernizations next, repatriations where the TCO gap is clear, and stays documented so they are not revisited without cause.
Crucially, the cloud TCO in step two must assume the optimization you will actually do, right sizing, commitment coverage, storage tiering, not the naive lift and shift cost. A workload that looks too expensive in the cloud at list price often clears once optimized, and a workload that looks cheap at list price often is not once egress and data transfer are counted.
A Fortune 500 retailer facing a datacenter lease expiry assumed it would lift and shift the whole estate. Scoring by archetype changed the plan: customer facing services were modernized to capture autoscaling savings, a large and stable batch analytics platform was repatriated because its steady state cloud cost exceeded fully loaded owned infrastructure, deadline bound systems were lifted as is and queued for a later optimization pass, and a handful of low value legacy systems were retired rather than moved. Sequencing by deadline and TCO, rather than moving everything at once, avoided a large block of cloud spend that the blanket plan would have locked in. Figures are verified against billing data and anonymised.
Where does negotiation fit?
Timing is leverage, so the framework feeds the commitment negotiation directly. A credible migration plan with a real deadline lets you negotiate migration funding, enterprise agreement tiers, and commitment terms from strength, and the option to place workloads on a different provider or keep them owned is the walk away that keeps a deal honest. Do not commit to multi year discounts until the framework has told you which workloads are actually moving and staying, because a commitment sized to a migration that does not happen carries the use it or lose it risk every enterprise agreement structure imposes. The negotiation mechanics are in the cloud commitment negotiation guide.
Frequently asked questions
Run the framework with us
We score your estate by archetype, model the honest post optimization TCO on each path, and sequence the move so deadlines and savings line up, independent and on your side of the table. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
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.