What a migration payback period actually measures
A cloud migration is one large payment now against a stream of smaller differences later. The payback period is the point at which the accumulated run-rate difference equals what you spent to get there. It is the first question a CFO asks and the last one an architecture deck usually answers.
Two things make the comparison harder than it looks. The first is that the on-premises estate is mostly capital — you bought the hardware once and it sits on the balance sheet — while the cloud estate is entirely operating expense. Comparing an annual cloud bill against this year's data centre invoices flatters the cloud badly, because this year's invoices exclude the servers you bought three years ago. Spreading the purchase cost over the refresh cycle is what puts both sides on the same footing.
The second is that a migration rarely removes all of the cost it appears to remove. Racking and cabling goes away; capacity planning, patching, identity, network design and cost governance do not. They change shape and move to a different team. This calculator makes you state that explicitly through the staff retained field, because leaving it out is the single most common way a business case overstates the saving.
The output that matters most is not the payback period on its own but the net present value. Payback ignores everything after the break-even point and ignores the time value of money entirely; NPV does neither. Use payback as the intuition and NPV as the decision.
How each side of the comparison is built
The on-premises annual cost has five components. Hardware is divided by the refresh cycle, so a $900,000 purchase on a five-year cycle contributes $180,000 a year. Maintenance covers vendor support contracts and hypervisor licensing. Power and cooling is the metered electricity plus the heat you have to remove. Space is rack or cage rental including cross-connects. Staff is the fully loaded cost of the people who operate this estate — if you do not have that figure, the fully loaded engineering hour calculator derives it from salary.
The cloud annual cost has three. Compute and storage is the annualised bill for instances, volumes, object storage and managed databases; if you are sizing that from scratch, work it up in the cloud VM monthly cost calculator first and check whether commitments change the number using the reserved versus on-demand break-even calculator. Egress is outbound and inter-zone traffic, which is the line that most reliably comes in above forecast — the egress budget calculator exists because of it. Support is charged as a percentage of spend, so it is applied as a multiplier on the other two rather than as a flat figure.
Retained staff is added to the cloud side rather than subtracted from the on-premises side. Both treatments give the same difference, but adding it makes the cloud column show the true total cost of running in the cloud, which is the number you will be asked to defend in a year's time.
The one-off cost is the migration project plus the cloud spend during parallel running. During the overlap you are paying for both estates, and the incremental amount is the cloud bill, because the data centre was already being paid for. Two months of parallel running on a $770,000 cloud estate is $128,333 of pure duplication that belongs in the payback numerator, not in the run rate.
Worked example: a 5-year case for a mid-sized estate
Take the default figures: $900,000 of hardware on a five-year refresh, $120,000 of maintenance, $72,000 of power and cooling, $60,000 of data centre space, and $480,000 of infrastructure staff. The cloud target is $400,000 of compute and storage, $60,000 of egress, a 10% support plan, and 55% of the infrastructure staff retained. The project costs $250,000 with two months of parallel running, over a five-year horizon at an 8% discount rate.
- Amortise the hardware. $900,000 ÷ 5 = $180,000 a year.
- Total the on-premises side. $180,000 + $120,000 + $72,000 + $60,000 + $480,000 = $912,000 a year.
- Apply support to the cloud run rate. ($400,000 + $60,000) × 1.10 = $506,000.
- Add the staff you keep. $480,000 × 55% = $264,000. Cloud total = $506,000 + $264,000 = $770,000 a year.
- Take the difference. $912,000 − $770,000 = $142,000 a year.
- Price the parallel running. 2 × ($770,000 ÷ 12) = $128,333. One-off total = $250,000 + $128,333 = $378,333.
- Divide. $378,333 ÷ $142,000 = 2.664 years, and 2.664 × 12 = 32.0 months.
- Net at five years. $142,000 × 5 − $378,333 = $331,667.
- Discount it. The five-year annuity factor at 8% is (1 − 1.08⁻⁵) ÷ 0.08 = 3.99271. So $142,000 × 3.99271 = $566,965, and NPV = $566,965 − $378,333 = $188,631.
Read those two closing figures together. The undiscounted five-year net is $331,667; discounting at 8% cuts it to $188,631 because the savings arrive over five years while the cost is paid immediately. Both are positive, so the case clears at this hurdle rate.
How to read the result
Payback inside the refresh cycle is the practical test. If the payback period is shorter than the remaining life of the hardware you are replacing, the move competes directly with buying that hardware again, and the comparison is honest. If payback runs past the next refresh, you are comparing against a purchase you would have had to make anyway, and the on-premises column should be rebuilt around the replacement cost rather than the sunk one.
A negative NPV with a positive annual difference means the saving is real but arrives too slowly for the hurdle rate. That is a financing conversation, not an engineering one, and it is often solved by shortening the parallel-running window rather than by finding more savings.
Be suspicious of any case where the annual difference is more than about a third of the on-premises total. Differences that large almost always mean the cloud side is under-scoped — commonly missing egress, missing non-production environments, missing backup and disaster recovery, or assuming a headcount reduction nobody has agreed to. Price the recovery side separately in the backup and DR cost calculator and add it to the cloud column before you believe the number.
When the run-rate difference is negative, the move can still be right, but it has to be argued on things this calculator does not measure: elasticity for spiky workloads, the exit from a capacity purchasing cycle, faster provisioning, or access to managed services that would otherwise be built. Say that plainly rather than adjusting inputs until the number turns positive.
Payback period against annual saving and one-off cost
| Annual saving | $250,000 one-off | $500,000 | $750,000 | $1,000,000 |
|---|---|---|---|---|
| $50,000 | 60.0 | 120.0 | 180.0 | 240.0 |
| $100,000 | 30.0 | 60.0 | 90.0 | 120.0 |
| $142,000 | 21.1 | 42.3 | 63.4 | 84.5 |
| $200,000 | 15.0 | 30.0 | 45.0 | 60.0 |
| $400,000 | 7.5 | 15.0 | 22.5 | 30.0 |
The $142,000 row is the worked example's annual saving. Its $250,000 column shows 21.1 months because that column excludes the parallel-running cost; adding the example's $128,333 of duplication is what moves it to 32.0 months.
What sinks a migration business case
- Comparing this year's data centre invoices to a full cloud bill. The invoices exclude hardware you already own. Amortise the purchase cost over the refresh cycle or the comparison is not a comparison.
- Assuming headcount falls to zero. Cloud estates need platform, security and cost-governance work that did not exist before. If nobody has signed up to a specific reduction, set staff retained at 100% and see whether the case still clears.
- Leaving out non-production. Development, test, staging and training environments are often half the instance count. They migrate too, and they run on the same bill.
- Forgetting egress. Inbound transfer is usually free and outbound is not. Backups leaving the region, inter-availability-zone chatter and customer downloads all bill, and none of them appear in an instance-price estimate.
- Ignoring the parallel-running window. Every month you run both estates is a full month of duplicated spend. It is one-off cost, it belongs in the numerator, and it is the input most often set to zero out of optimism.
- Treating the first cloud bill as the run rate. Right-sizing after migration typically moves the number, in both directions: idle capacity comes out, but so does the assumption that a lift-and-shift instance matches its physical predecessor.
What this calculator deliberately leaves out
It does not model residual value on the hardware you decommission, tax treatment of capital versus operating spend, or contractual exit costs from a colocation agreement. All three are real and all three are jurisdiction- and contract-specific, so putting default numbers on them would be inventing figures rather than calculating them. Add them yourself: hardware resale proceeds reduce the one-off cost, and an unexpired colocation term that you keep paying after cut-over increases it.
Where this sits among the other decisions
Payback answers whether the move pays for itself. It does not answer whether the workload should exist in this form at all. Before running the case, it is worth asking whether the application is a candidate for replacement rather than migration — the build versus buy calculator frames that trade, and the software TCO calculator covers the full ownership cost of a packaged alternative.
If the workload stays but carries structural drag, the migration is also the moment that drag becomes visible, because you re-platform every piece of it. Quantify what that drag costs annually in the technical debt interest calculator and decide whether to pay it down during the move or after it. Paying it down during a migration is usually cheaper in effort and more expensive in schedule risk.
Finally, migrations concentrate outage risk into a small number of cut-over windows. Put a number on what a bad window would cost using the IT downtime cost calculator, and let that number set the budget for rehearsal and rollback rather than leaving it as an unpriced worry. A case with a 32-month payback has very little room for a single expensive weekend.
Key terms
- Run rate
- The recurring annual cost of operating an estate, excluding one-off project spend. Both columns in this calculator are run rates.
- Parallel running
- The period during cut-over when both the old and new environments are live. The incremental cost is the new environment's bill, because the old one was already committed.
- Payback period
- The time for cumulative savings to equal the one-off cost. It ignores everything that happens after break-even and ignores the time value of money.
- Net present value
- The sum of all future differences discounted back to today at your cost of capital, less the immediate outlay. A positive NPV means the project clears the hurdle rate.