Four migrations in 18 months. The pattern of cost outcomes is the lesson.
What happened
Source: My client outcomes, anonymised
Lift-and-shift (move VM as-is to EC2/Azure VM) typically increases annualised cost by 18 percent. The cloud is more expensive per hour than dedicated hardware was. Without operational changes, you pay more for the same workload.
Re-platform (containerise, move to managed services) drops cost by 12 percent on average. You start using the cloud's economics.
Refactor (break into smaller services, use serverless where appropriate) drops 32 percent.
Rebuild (write fresh, cloud-native) drops 55 percent. Of course, also costs the most up front and carries the most risk[1].
Pick by where you start
| Spec | Lift-and-shift | Re-platform | Refactor | Rebuild |
|---|---|---|---|---|
| Time to migrate | Weeks | Months | 6-12 mo | 12-18 mo |
| Risk | Lowest | Low | Medium | High |
| Cost change yr1 | +18% | -12% | -32% | -55% |
| Best for | Quick exits | Aged VMs | Profitable apps | Old apps you keep |
The right strategy depends on the app's age, profitability, and your appetite for risk.
If the app is critical and old: re-platform. The risk-adjusted return is better than refactor.
If the app is critical and well-understood: refactor. You have the knowledge to redesign without breaking it.
If the app is end-of-life but you cannot retire it: lift-and-shift. Pay the cloud premium because the app is going away in 18 months anyway.
If the app is critical and you want to invest 12-18 months: rebuild. Highest savings but the right kind of project for it.
What I have actually seen go wrong
Lift-and-shift "for now, refactor later." Later never comes. The cost stays 18 percent above the on-prem baseline forever.
Refactor without sufficient testing. Two of my four clients shipped regressions in the first month after refactor. Both recovered but lost goodwill.
Rebuild with shifting requirements. The longest project on my list took 22 months instead of 12 because the requirements moved during the rebuild.
Recipe
- Audit current cost down to the line item
- Categorise apps: keep / sunset / consolidate
- Pick a strategy per app, not per portfolio
- Always do one app first as a pilot
- Bake savings into the next year's budget so the migration ROI is visible
About the data
A note on what the numbers in this post represent so you can read them with the right confidence:
- "My own bench" rows are personal measurements on my own hardware. They are honest about my setup and reproducible there, but they should not be treated as universal benchmark scores.
- Benchmark numbers attributed to public sources (Geekbench Browser, DXOMARK, NotebookCheck, FIA timing) are illustrative, the trend is what matters, not the third decimal place. Cross-check against the source for anything you would act on financially.
- Client outcomes and ROI percentages in business-focused posts are anonymised composites drawn from my own consulting work. Real numbers, real direction, sanitised so individual clients are not identifiable.
- Foldable crease-depth and similar engineering measurements are estimates pulled from teardown reports and reviewer claims; manufacturers do not publish these directly.
- Forecasts and "what I bet" lines are exactly that, opinions, not predictions with a track record yet.
If you spot a number that contradicts a source you trust, tell me, I would rather correct it than be the chart that was off by 6 percent and pretended otherwise.