Cloud migration cost analysis: building a TCO and business case
A cloud migration cost analysis compares what you pay to run a workload today with the one-off cost of moving it and the running cost in the cloud, over three to five years. It covers four buckets: migration project costs, a period of running both environments, new cloud run costs, and the people and licence changes that come with them.
Key takeaways
- Model total cost of ownership (TCO) over three to five years, not the first cloud invoice. Migration cost is a one-off; run cost and operations decide the outcome.
- The migration strategy drives the number. AWS lists seven options (the 7 Rs), from retire and rehost to refactor, and each has a different cost profile.
- Budget for the "double bubble": you pay for on-premises and cloud at the same time until the old environment is switched off.
- Licences, data transfer and idle capacity are the costs most often missed. Flexera's 2026 State of the Cloud survey puts estimated wasted IaaS and PaaS spend at 29%.
- Use the free tools (AWS Migration Evaluator, AWS Pricing Calculator, Azure Migrate business case) for a first estimate, then validate with real utilisation data.
- Right-sizing and cost governance after go-live matter as much as the migration plan itself.
What does a cloud migration cost?
There is no single price. The cost depends on how many applications you move, how much you change them, how much data you transfer and how long you run two environments in parallel. What you can do is break the cost into parts you can estimate and check.
| Cost bucket | What it includes | How to estimate it |
|---|---|---|
| Assessment and planning | Discovery, dependency mapping, business case, landing zone design | Fixed-scope project or internal hours; often partly funded by cloud provider programmes |
| Migration execution | Engineering work per application, testing, cutover, tooling | Effort per application by strategy (rehost, replatform, refactor), times the number of applications |
| Parallel running ("double bubble") | On-premises hardware, hosting, support contracts and cloud resources at the same time | Monthly cost of both environments times the overlap period in your plan |
| Data transfer | Moving data in, ongoing traffic out to the internet or between regions | Data volumes and traffic patterns priced in the provider's calculator |
| Cloud run costs | Compute, storage, databases, networking, backup, monitoring, security services | Right-sized resources from utilisation data, with commitment discounts where load is stable |
| Licences | Windows Server, SQL Server, Oracle, third-party software, support renewals | Check bring-your-own-licence (BYOL) rights against licence-included prices |
| People and operations | Training, new roles (cloud operations, FinOps), managed service fees | Internal staffing plan or managed service quote |
How the migration strategy changes the cost
The more you change an application during the move, the higher the project cost and the larger the possible run-cost saving. AWS prescriptive guidance describes seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor.
- Retire: switch off applications nobody needs. This is the cheapest saving in any migration and often the first one finance notices.
- Retain: keep an application where it is for now, for example for latency, licensing or end-of-life reasons.
- Rehost (lift and shift): move virtual machines as they are. Low project cost and short timelines, but you carry over oversized servers and existing technical debt.
- Relocate: move a whole platform, such as VMware, to a cloud-hosted version without changing each VM.
- Repurchase: replace the application with SaaS. Project cost shifts to data migration and change management; run cost becomes a subscription.
- Replatform: make targeted changes, such as moving a database to a managed service or adding auto-scaling, without a rewrite. Read more in our replatforming guide.
- Refactor: redesign the application for cloud-native services. Highest project cost and longest timeline, with the most room to lower run cost and speed up delivery.
AWS's own guidance does not recommend refactoring during large migrations because it is the most complex strategy. It suggests rehosting, relocating or replatforming first and modernising after the move. That matches what we see in practice: most estates move in waves, with a small number of high-value applications refactored later.
| Rehost | Replatform | Refactor | |
|---|---|---|---|
| Project effort | Low | Medium | High |
| Time to move | Shortest | Medium | Longest |
| Run-cost potential | Limited without right-sizing | Good: managed services, auto-scaling | Highest: usage-based services |
| Main risk | Paying cloud prices for on-premises sizing | Scope creep into a rewrite | Budget and timeline overrun, skills gap |
| Good fit | Data centre exit deadline, stable legacy apps | Databases, web tiers, seasonal load | Core products that need frequent change |
Hidden costs that break migration budgets
Most overruns come from a handful of items that were not in the first spreadsheet.
Licences
Licence terms often differ in the cloud. Some licences can be brought along; others must be bought again as licence-included instances. AWS Migration Evaluator compares bring-your-own-licence and licence-included options, and the Azure Migrate business case models savings from Azure Hybrid Benefit and Extended Security Updates. For SQL Server past end of support, the Azure Migrate business case assumes Extended Security Update costs of 75%, 100% and 125% of the licence cost in years one to three, which is a useful reminder of what staying put can cost.
Data transfer
Moving data into the cloud is usually free, but traffic out to the internet and between regions is billed per GB. On AWS, the EC2 pricing page lists free inbound transfer and a 100 GB monthly free allowance for outbound traffic, aggregated across services. Applications that serve large files or replicate data across regions need this modelled explicitly.
Parallel running
Hardware support, hosting contracts and licences keep running until the last workload leaves. A delayed cutover of one dependent system can hold the whole data centre open. Plan the decommissioning dates as carefully as the migration dates.
Idle and oversized resources
On-premises servers are sized for peak load plus headroom. Copying those sizes to the cloud means paying for capacity you do not use every hour. Flexera's 2026 State of the Cloud Report found that estimated wasted spend on IaaS and PaaS rose to 29%, after five years of decline.
Skills and operations
Running cloud well needs different skills: infrastructure as code, cost management, cloud security. Either train your team, hire, or use a managed service provider. All three cost money and should be in the model.
How to build a cloud migration cost model
Build the model bottom-up per application, then roll it up. Six steps cover most cases.
- Inventory. List applications, servers, databases, storage and dependencies. Collect real CPU, memory and storage utilisation for at least a few weeks, including peak periods.
- Baseline today's cost. Hardware depreciation, hosting or data centre space, power, network, licences, support contracts and the staff time spent running it.
- Pick a strategy per application. Use the 7 Rs. Tag each application with an expected strategy and a confidence level.
- Estimate cloud run cost. Price right-sized resources in the provider's calculator, then apply savings plans or reservations only to load that is stable.
- Add one-off and transition costs. Migration effort, tools, training, parallel running and contingency.
- Calculate and test. Compare cumulative cost of "stay" and "move" over three to five years, then change the key assumptions to see which ones flip the result.
The formulas you need
- TCO = one-off migration costs + (monthly run cost × months in the period) + people and licence costs over the same period.
- Payback period = one-off migration costs ÷ monthly saving, where monthly saving = current monthly cost − new monthly cost.
- ROI = (total benefit − total cost) ÷ total cost, where benefit can include avoided hardware refresh and reduced downtime as well as lower bills.
Run at least three scenarios: expected, pessimistic (longer parallel running, slower right-sizing) and optimistic. If the decision only works in the optimistic case, the plan needs more work.
Tools for estimating migration cost
- AWS Migration Evaluator builds a business case from discovery data and identifies over-provisioned on-premises servers.
- AWS Pricing Calculator prices individual services and architectures.
- AWS Migration Acceleration Program (MAP) follows an Assess, Mobilize, Migrate and Modernize approach and can provide funding and tools through migration partners.
- Azure Migrate business case estimates on-premises versus Azure TCO and year-over-year cash flow.
- Your own spreadsheet for the items the tools do not see: contract end dates, staff costs, risk and contingency.
Example: Branäsgruppen's move to AWS
Branäsgruppen, one of Sweden's largest ski resort groups, does most of its trade between December and April. Its VMware-based on-premises setup had to be scaled by hand before each peak, and deployments meant taking the environment down.
Opsio migrated the estate to AWS with a replatform approach: application logic stayed, while servers and databases moved to AWS-managed services with auto-scaling and Multi-AZ deployment. According to the Branäsgruppen case study, the result was a 40% reduction in total cost of ownership, 40% better average page responsiveness and 99.9%+ application uptime. The TCO reduction came from pairing right-sized auto-scaling with FinOps practices, which shows that the post-migration cost discipline matters as much as the move itself.
How to keep costs under control after go-live
- Tag every resource with owner, application and environment from day one.
- Set budgets and alerts per account or subscription.
- Review right-sizing recommendations monthly for the first quarter, then quarterly.
- Buy commitments (savings plans, reservations) only after usage has stabilised.
- Switch off non-production environments outside working hours.
- Track cost per business unit or per transaction, not only the total bill.
Our cloud cost optimisation service covers these steps for teams that do not want to build a FinOps function in-house.
How Opsio helps
Opsio is an AWS Advanced Tier partner with the AWS Migration Competency. Our AWS migration service runs in three phases (assess, mobilize, migrate), starting with an inventory and business case built on your utilisation data. See our cloud migration services or read how long a cloud migration takes to plan the timeline side of the budget.
Frequently asked questions
How much does it cost to migrate to the cloud?
It depends on the number of applications, the strategy for each, data volumes and how long you run both environments. Estimate it per application, add parallel running and licence changes, and compare with today's cost over three to five years.
Is lift and shift cheaper than refactoring?
Lift and shift is cheaper and faster to execute. Refactoring costs more up front but can lower run costs and speed up delivery. Many organisations rehost or replatform first and refactor selected applications later.
What hidden costs should I include?
Licences that do not transfer, outbound data transfer, parallel running of old and new environments, oversized cloud resources, training and new operational roles.
How do I calculate the payback period of a migration?
Divide the one-off migration cost by the monthly saving (current monthly cost minus new monthly cost). Include people and licence costs on both sides so the comparison is fair.
Are there free tools to estimate cloud migration costs?
Yes. AWS Migration Evaluator, the AWS Pricing Calculator and the Azure Migrate business case are free to use. They give a first estimate that you should validate with real utilisation data.
Related reading: Cloud Cost Analysis.
Related Articles
About the Author
Editorial standards: This article was written by a certified practitioner, named in the byline above. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.
