Cloud migration has no standard price
Two organisations can move the same number of virtual machines and spend radically different amounts. The difference is rarely the provider logo. It is the applications, dependencies, data, security requirements, operating model, and acceptable level of risk behind the move.
A small, well-documented application with a straightforward database may be moved and stabilised in weeks. A portfolio of older systems that share identity services, file stores, batch jobs, third-party interfaces, and strict uptime requirements can become a multi-phase programme. The infrastructure bill matters, but it is only one part of the budget.
The useful question is not “How much does a cloud migration cost?” It is: “What will it take to move this estate safely, operate it well, and achieve a better commercial outcome than we have today?”
Separate migration cost from cloud run-rate
A migration budget should distinguish between the one-off cost of discovery, design, migration, testing, cutover, and stabilisation; the temporary cost of running source and target environments in parallel; and the ongoing cost of operating the new platform.
Those are related, but they should not be blended into one headline number. A low implementation cost can create an expensive operating model if workloads are lifted and shifted without right-sizing, automation, governance, or clear ownership. Equally, a larger up-front investment in platform foundations and selective modernisation can lower operational risk and avoid years of unnecessary spend.
AWS Migration Evaluator and Azure Migrate assessments can establish an initial infrastructure business case. They are useful starting points, not final programme budgets: application-level design, delivery planning, and cutover analysis still need to be costed.
What belongs in a migration budget?
A practical migration budget has two connected views:
- Migration programme cost: discovery and design, platform foundations, workload migration, data transfer, parallel running, testing, cutover, stabilisation, delivery, and change management.
- First-year cloud cost: cloud consumption, licences and support, security, backup, observability, disaster recovery, managed operations, and optimisation work.
The aim is not false precision. It is to identify the categories that need evidence, assign owners, and show which assumptions could materially change the decision.
Application complexity matters more than server count
Counting servers is quick, but it is not a reliable way to estimate migration effort. A server may be simple to move; the application it supports may not be.
The largest delivery variables are usually undocumented dependencies, bespoke integrations and scheduled batch processes, shared databases, old operating systems or middleware, hard-coded network assumptions, local file stores, legacy authentication, and data sensitivity. A portfolio with 100 independent low-risk workloads may cost less to move than ten critical systems with shared identity, data replication, and narrow maintenance windows.
Discovery therefore needs to look beyond infrastructure inventory. It should capture application ownership, interfaces, data flows, recovery requirements, release processes, support arrangements, and the business consequence of failure. Westpoint's cloud consultancy work starts from these operating constraints, because the route that appears cheapest on an infrastructure diagram can be costly once live dependencies appear.
The migration approach changes cost and risk
“Lift and shift” is often presented as the low-cost option. It can be, particularly when a workload needs to leave a data centre quickly or has limited strategic value. But rehosting preserves much of the existing architecture, including inefficient sizing, manual deployment, fragile failover, and unnecessary licensing.
| Approach | Up-front cost | Long-term operating impact |
|---|---|---|
| Rehost | Lower | Often retains technical debt |
| Replatform | Moderate | Can improve manageability and run-rate |
| Refactor or rearchitect | Higher | May improve resilience, delivery speed, and unit cost |
| Retire or replace | Variable | Can remove spend and operational burden |
The right answer is normally a portfolio decision. Rehost a stable, low-change workload. Replatform a database where managed services reduce operational burden. Refactor applications that constrain the business or create disproportionate resilience risk. Retire systems that no longer justify their support cost.
Landing-zone foundations are a real cost
AWS and Azure make it easy to provision individual resources. Building an environment that is secure, auditable, repeatable, and supportable takes deliberate work. The budget should include account or subscription structure, identity and privileged access design, network connectivity, encryption and secrets management, logging, policy controls, infrastructure as code, deployment pipelines, backup, disaster recovery, monitoring, tagging, budgets, and cost allocation.
These foundations are not overhead. They determine whether teams can deploy consistently, control access, investigate incidents, and understand their cloud bill. A well-designed cloud engineering foundation reduces later migration effort because each workload does not have to solve networking, secrets, logging, and delivery from scratch.
Data movement and coexistence can be expensive
Data is frequently the hardest part to schedule. The cost is not solely transfer charges. It includes extraction, cleansing, schema changes, replication, validation, downtime planning, and the period in which two environments must remain consistent.
Questions that change the budget include how much data must move, how quickly it changes, whether it can be copied in advance, whether historic records can be archived, whether cross-region or third-party transfer charges apply, and how completeness will be reconciled. A small but continuously changing transactional data set can be more difficult than a much larger archive.
The budget should include a rehearsal. A migration that has not been timed, tested, and reconciled is an estimate, not a plan.
Licensing, resilience, and security affect the economics
For organisations with significant Microsoft, database, middleware, or third-party software estates, licensing may be one of the largest variables in the business case. Windows Server and SQL Server workloads can have different economics depending on existing agreements, licence eligibility, target architecture, and the use of managed services.
The model should separate licences retained after migration, licences removed by retiring infrastructure or applications, licences replaced by cloud-native services, and new charges for operating systems, databases, security, and support. Do not assume that a licensing benefit applies until entitlement and support terms have been reviewed.
Cloud also does not automatically make a workload highly available, secure, or compliant. A system that must tolerate an availability-zone failure may require redundant components and replicated data. A regulated workload may need enhanced logging, retention, encryption, private connectivity, and evidence-producing operational processes. Each is a justified cost where it meets a real business requirement; the mistake is applying premium resilience everywhere or leaving controls until a review blocks cutover.
Parallel running, decommissioning, and people
During a migration, organisations may pay for the old data centre or hosting contract while also paying for cloud environments, replication, testing, and tooling. This overlap is normal. It becomes expensive when it is indefinite because decommissioning was not planned or nobody has authority to shut down the old service.
Treat decommissioning as a funded workstream. Capture contract end dates, hardware refresh timing, software renewals, data-retention obligations, and dependencies on shared services. Savings should not be claimed until the exit activity needed to realise them has a plan.
The programme also needs capacity from application owners, security teams, operations, service desks, and business users who must test and approve cutovers. The risk is not that internal teams lack skill; it is that they are already keeping production systems running. A plan that assumes unlimited access to experts usually takes longer and costs more than forecast.
Use FinOps from the first workload
A credible cloud budget includes ongoing optimisation. The run-rate should be managed through ownership, tagging, budgets, usage reviews, commitment decisions, and architecture improvements. Set resource ownership and budgets before production cutover, measure utilisation after migration, schedule non-production environments where appropriate, and review storage growth, backup retention, network paths, and idle resources.
Commitment-based savings can help stable workloads, but they should follow right-sizing and observed usage rather than precede them. The goal is not simply to spend less. It is to get more value from each pound or dollar spent while protecting the reliability and delivery capability the business needs.
Build the estimate in stages
Start with a range rather than a single number. First, inventory workloads, classify criticality, identify likely migration paths, and model initial consumption. Next, validate high-risk systems: shared identity, data stores, integrations, regulated workloads, and applications with difficult availability requirements. Then move a representative workload, validate the operating model, measure effort, and run a cutover rehearsal.
Use that evidence to reforecast delivery capacity, wave duration, run-rate, parallel-running costs, and decommissioning dates before scaling the programme. The business case should show the range of outcomes, the assumptions behind each one, and the decisions that could change it.
The bottom line
Cloud migration cost is shaped less by AWS or Azure pricing alone than by the condition of the estate and the standard of delivery. Calculators can model services. A useful budget also accounts for discovering dependencies, establishing secure foundations, moving data, protecting uptime, training teams, retiring old systems, and operating the new platform responsibly.
The best first step is a focused assessment of the applications that create the most commercial or operational risk. It produces a more defensible budget, a clearer migration sequence, and fewer surprises at cutover. For an example of a complex migration framed around business outcomes and continuity, see Westpoint's Toyota cloud migration case study.
