How to evaluate a cloud migration before you commit

1. Establish what you spend today, in full

Your current run cost is almost never the number in the hosting invoice. Build the total from every line that disappears — or does not — if the workload moves.

• —Hardware amortisation and the remaining book value of anything you would retire early.
• —Facility costs: rack space, power, cooling, cross-connects.
• —Licences tied to sockets, cores or physical hosts, and what those become under a different model.
• —Support contracts, including the ones auto-renewing next quarter.
• —Staff time actually spent on patching, backup verification and capacity work — measured, not estimated.

Write down which of those costs are genuinely avoidable. A cost you keep paying after migration belongs on both sides of the comparison, not just the current one.

2. Classify each workload by what migration would demand of it

Treating a portfolio as one migration hides most of the cost. Give every workload a disposition before costing anything. These are the dispositions we find most useful as a starting point, not a complete taxonomy — published migration frameworks describe further options, and a single portfolio often needs several.

• —Retain — stays where it is, at least for now. A perfectly valid answer, and the right one for workloads with hardware dependencies, contractual constraints, imminent replacement, latency or data-location requirements, or simply no case for moving. Deciding to retain deliberately is not a failure to migrate.
• —Retire — still running, no longer needed. Cheapest possible outcome.
• —Rehost — moves as-is. Fast, but inherits existing inefficiency and its cost profile.
• —Replatform — managed database, managed queue, container runtime. Moderate effort, much of the operational upside.
• —Rebuild or replace — the architecture cannot follow. Price this as a product project, not a migration task.

The mix matters more than any single workload: a portfolio weighted towards retain and rehost moves quickly, while one weighted towards rebuild behaves like a development programme and should be planned as one.

3. Model the run cost against representative usage, including peaks

On-premise capacity is usually sized for the worst hour of the year. Cloud is billed for the hour you are in. Pull at least twelve months of CPU, memory, IOPS and egress and model against the actual distribution rather than a single number.

1. 01Describe the workload's real shape: its steady state, its peaks, how often peaks occur and how quickly they arrive. Percentiles are a useful summary — a high percentile such as the 95th is a common illustration of steady state — but no percentile is a universal sizing rule, and peaks you clip are outages, not savings.
2. 02Size against the workload's own requirements: latency and throughput targets, burst behaviour, batch windows, seasonal events, and how fast capacity can actually scale in response.
3. 03Add explicit headroom for growth, for failover (capacity that must absorb a failed node or zone) and for maintenance, then say what that headroom is for.
4. 04Set recovery targets before pricing, and include the standby or replica capacity they require. Resilience is capacity you pay for, not a setting.
5. 05Price the durable base on committed or reserved capacity and the variable part on on-demand, then check the commitment still holds if demand shifts.
6. 06Add data transfer explicitly — inter-region and internet egress are the two lines most often missing.
7. 07Add the storage class you will really use once retention and backup policy are applied.
8. 08Re-run the model at higher and lower demand — say 1.5x and 0.6x — to see how the case behaves if the business does not grow as planned.

4. Cost the transition, not just the destination

The transition period is where migrations lose their business case. Budget it as a named line item with its own end date.

• —Parallel running: both environments live, both billed, for the length of the cutover window.
• —One-off data movement, plus any dedicated network link provisioned for it.
• —Engineering effort for replatform and rebuild work, at a rate you would actually pay.
• —Testing, including at least one full rehearsal of the cutover and its rollback.
• —Training and the productivity dip in the first weeks on new tooling.

5. Decide what resilience you are actually buying

Migration does not make a system resilient; it changes the menu of resilience you can purchase. Set the targets first, then price the architecture that meets them.

• —Recovery time objective: how long the business can be down before the impact becomes material.
• —Recovery point objective: how much data loss is tolerable, stated in minutes.
• —Which failure you are designing against — instance, availability zone, region, or provider account compromise.
• —How the target is verified, and how often. An untested target is an aspiration.

6. Name the lock-in you are accepting on purpose

Managed services are usually worth their coupling. The mistake is accepting the coupling without noticing. For each managed service, record what replacing it would take: a config change, a rewrite of one component, or a rewrite of the system.

That single column turns an abstract argument about lock-in into a list of specific, priced exits — some of which you will happily never take.

7. Write the decision down before you start

One page, dated: the option chosen, the two you rejected, the numbers you relied on, the assumptions behind them, and the conditions that would make you revisit it.

Eighteen months later, when someone asks why the platform looks like this, that page is the difference between an architecture with reasons and an architecture with archaeology.