Free calculator · Cloud
Estimate cloud migration cost, timeline and payback
Sort your workloads by the 7 Rs migration strategies, enter the effort and your team's weekly cost, then the hosting cost before and after. The estimator adds up the one-time cost, including dual running, and shows the timeline and how many months of saving repay it.
How this is calculated
The estimator adds up the engineering effort for each workload by migration strategy, prices it at your weekly team cost, adds dual running and other one-off costs, and compares the total with the monthly saving between today's running cost and the expected cost after the move.
Step by step
- Effort: for each of the 7 Rs, workloads × team-weeks per workload, added together.
- Engineering cost: total team-weeks × the weekly cost of one team.
- Timeline: total team-weeks ÷ teams working in parallel gives the calendar weeks of migration work; 52 weeks count as 12 months.
- Dual running: months of dual running × the extra cost per month while both environments run.
- One-time cost: engineering + dual running + other one-off costs.
- Monthly saving: today's monthly running cost − the expected monthly cost after the migration.
- Payback: one-time cost ÷ monthly saving, in months from when the saving starts. A saving of zero or less has no payback on hosting cost alone.
- Net over the period: the monthly saving for the months left after migration and dual running, minus the one-time cost.
Default assumptions
Assumptions marked adjustable can be changed in the calculator; the others are fixed parts of the model.
| Assumption | Default | Sources |
|---|---|---|
| Monthly running cost today (example)adjustable | $30,000 a month | |
| Expected monthly cost after migration (example)adjustable | $22,000 a month | |
| Workloads to retireadjustable | 2 workloads | |
| Workloads to retainadjustable | 2 workloads | |
| Workloads to rehostadjustable | 3 workloads | |
| Workloads to relocateadjustable | 0 workloads | |
| Workloads to repurchaseadjustable | 0 workloads | |
| Workloads to replatformadjustable | 1 workload | |
| Workloads to refactoradjustable | 1 workload | |
| Effort to retire a workloadadjustable | 0.5 weeks per workload | None |
| Effort to retain a workloadadjustable | 0 weeks per workload | None |
| Effort to rehost a workloadadjustable | 1 week per workload | None |
| Effort to relocate a workloadadjustable | 1 week per workload | None |
| Effort to repurchase a workloadadjustable | 2 weeks per workload | |
| Effort to replatform a workloadadjustable | 2 weeks per workload | None |
| Effort to refactor a workloadadjustable | 4 weeks per workload | |
| Cost of one migration team per weekadjustable | $10,000 a week | None |
| Teams working in paralleladjustable | 1 team | None |
| Months of dual runningadjustable | 2 months | None |
| Extra cost per month of dual runningadjustable | $20,000 a month | None |
| Other one-off costsadjustable | $20,000 once | None |
| Period for the net resultadjustable | 36 months | None |
What this doesn’t model
- Effort per workload is one figure per strategy; real workloads of the same strategy vary a lot in size.
- The saving is a flat monthly amount from the end of dual running; it does not ramp up as workloads move.
- Parallel teams divide the calendar evenly, ignoring dependencies between workloads.
- Every default is an example, not a benchmark or a quote.
- Discovery, assessment and planning before migration work starts, unless you add them as one-off costs.
- Savings from workloads that finish early; the saving is counted only once every workload has moved and dual running has ended.
- Operations or maintenance time saved or added after the move, unless it is part of the monthly costs you enter.
- Price changes, growth in usage, discounts and currency movements over the period.
- Financing costs, depreciation, hardware resale value and tax treatment.
- The business cost of downtime or degraded service during cutover.
Sources
- Amazon Web Services, About the migration strategies (Guide for AWS large migrations). Accessed . Defines the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. It calls refactor the most complex and costly strategy and recommends rehosting, relocating or replatforming first in large migrations, then modernising.
- Google Cloud, Migrate to Google Cloud: Get started (20 Nov 2024). Accessed . Names the migration types (rehost, replatform, refactor, re-architect, rebuild, repurchase) and four phases: assess (including total cost of ownership), plan, deploy and optimise.
Last reviewed by the QuantmHill engineering team. Found an error?
Link to or cite this tool
Writing about this topic? Link to the calculator or cite it. Its method, defaults and sources are all on this page, so readers can check the numbers.
Embed this calculator
You can put this calculator on your own site for free. Paste the code below where it should appear. It loads the same calculator in a frame, with a link back to this page for the full method and sources.
The credit line links to this page with the anchor text “QuantmHill”. You may edit it, add rel="nofollow" or remove it — the calculator works the same either way. Add ?theme=light or ?theme=dark to the iframe address to fix its colour scheme; otherwise it follows the visitor's system setting.
Add this once per page, after the iframe, if you want the frame to grow and shrink with the calculator instead of using the fixed height above. It accepts messages from quantmhill.com only and resizes only the frame that sent them.
Frequently asked questions
The one-time cost of a migration (engineering effort, dual running and other one-off costs), how long the work takes with the teams you enter, the monthly saving from the hosting costs before and after, and the months of saving needed to repay the one-time cost. Every figure comes from your inputs.
The seven migration strategies in AWS Prescriptive Guidance: retire, retain, rehost (lift and shift), relocate, repurchase, replatform, and refactor or re-architect. AWS calls refactoring the most complex and costly, and for large migrations recommends rehosting, relocating or replatforming first and modernising afterwards. Google Cloud's migration guide uses similar types.
Payback is the one-time cost divided by the monthly saving, counted from when the saving starts, after the migration work and any dual running. If the new environment costs the same or more than today, there is no payback on hosting cost alone, and the estimator says so instead of showing a number.
They are examples, not benchmarks. Neither AWS nor Google Cloud publishes effort per workload that would hold across organisations, so every effort figure and the weekly team cost are inputs. Size them from a pilot migration or your own past work.
Keeping the old environment running until the new one has proved itself lets you roll back, but you pay for both in the meantime. The estimator adds those months to the one-time cost and starts the saving after them.
No. You choose a strategy for each workload; the estimator prices the mix you enter. Changing a workload from refactor to rehost, for example, shows how the cost and timeline move.
Want an engineer to check your numbers?
Send us your inputs and the decision you're weighing. We'll reply within one business day with an honest read on whether we can help.