Why cloud migration ROI projections go wrong

The starting point for most cloud migration business cases is a comparison that seems obvious: what you currently spend on data center infrastructure versus what the equivalent cloud footprint would cost. The cloud estimate usually looks attractive. Infrastructure as a service is priced in ways that appear cheaper than owned hardware, and cloud providers make it straightforward to run workloads through a pricing calculator and arrive at a monthly figure.

The problem is that the comparison is structurally incomplete. It captures one cost on one side and a partial cost on the other.

The typical migration business case
On-premises infrastructure cost → Expected cloud infrastructure cost → Projected savings
This model compares a fully-loaded current cost against a partial future cost. The gap between them is often mistaken for ROI.
The complete cost model
Assessment + migration labor + consulting + application refactoring + temporary dual-infrastructure + data transfer + security tooling + observability + skills and hiring + licensing changes + FinOps + ongoing optimization + cloud operating costs (compute, storage, networking, databases, support) + business disruption
This model produces a realistic Total Cost of Ownership and a credible ROI projection.

Gartner research indicates that 60% of infrastructure and operations leaders encounter public cloud costs that exceed their original forecasts. The pattern is consistent across company sizes and cloud providers. The migration itself usually succeeds technically. The financial outcome is what surprises people, and the surprises are rarely positive.

The other structural error in cloud migration planning is treating migration as the end of the financial event rather than the beginning of a different operating cost model. On-premises infrastructure has a large capital expenditure upfront, then lower operating costs as the hardware depreciates. Cloud has lower upfront costs but ongoing variable operating expenses that change as workloads, usage, and the organization itself change. These are different economic models, and comparing them requires modeling the cloud operating cost over multiple years, not just the first-year estimate.

The cost categories most commonly missing from migration business cases
Before migration: assessment, application dependency analysis, architecture consulting, proofs of concept. During migration: engineering labor, temporary parallel environments, data movement, application remediation. After migration: cloud-native tooling, security platform expansion, observability, FinOps, ongoing right-sizing, skills development, and optimization. These categories are not edge cases. They are predictable and consistently underbudgeted.

The hidden costs that destroy cloud migration ROI

The following cost categories are the ones most consistently underestimated or absent from migration business cases. They are not unusual or rare, every enterprise cloud migration encounters most of them. The difference between organizations that hit their ROI projections and those that don't is usually whether these were modeled in advance or discovered after the fact.

1
Application refactoring and remediation
Often the largest single line item nobody modelled
What it is Not every application can move to the cloud unchanged. Applications built on operating systems no longer supported by cloud providers, applications with hard-coded IP addresses or on-premises paths, monolithic architectures that don't scale in cloud environments, and applications with database dependencies that require commercial licensing changes all require engineering work before or during migration. "Lift-and-shift" sounds free, but in practice it often reveals incompatibilities that require resolution before a workload can run reliably in the cloud.
Why it gets underestimated Legacy application inventories are often incomplete and inaccurate. Dependencies between applications are rarely fully documented. The true extent of remediation work surfaces during the discovery and pilot phases, not during the initial planning phase when the budget is set.
ROI impact Can be one-time but large. Kagool analysis of enterprise migrations found that addressing technical debt in legacy applications during migration can increase total migration costs by 40% or more compared to a lift-and-shift approach. Ignoring it produces higher recurring operating costs afterward, often 20-30% above optimised baselines.
How to model it Conduct a formal application portfolio assessment before finalising migration budgets. Classify each application by migration complexity (rehost, replatform, refactor, replace, retire). The refactor and replatform categories require engineering estimates, not infrastructure pricing.
How to reduce it Retire applications with no active users before migration. Replace commodity applications with SaaS equivalents rather than migrating them. Address the highest-complexity applications early in the programme to surface true costs before budget is fully committed.
2
Data egress and cross-service transfer costs
The cost nobody notices until the invoice arrives
What it is Moving data into most cloud providers is free or low-cost. Moving data out, to the internet, to another region, to another cloud service, or back to on-premises systems during the hybrid transition period, carries charges that vary by provider, region, and volume. During a migration where applications and data are temporarily split across environments, cross-environment calls can generate significant egress costs that are invisible in planning documents that only look at steady-state cloud pricing.
Why it gets underestimated Cloud pricing calculators model compute and storage clearly. Networking and data transfer charges require modeling actual traffic flows, which is difficult to do accurately before the environment exists. The hybrid transition period is particularly expensive because every cross-environment API call may incur transfer costs.
ROI impact Variable and recurring. At significant data volumes, egress can represent 10-12% of total monthly cloud spend, per Kagool's analysis of global enterprise clients. It grows with application usage and data volumes.
How to model it Map data flows between every application and external system before migration. Model egress costs during the hybrid period specifically, treating it as a temporary surcharge. Use provider pricing documentation for current egress rates: AWS data transfer pricing, Azure bandwidth pricing, and Google Cloud network pricing pages provide current per-GB rates by region.
How to reduce it For bulk data movement at scale, consider physical transfer services (AWS Snowball, Azure Data Box) rather than online transfer. For ongoing high-volume cross-region or hybrid traffic, dedicated connectivity options (AWS Direct Connect, Azure ExpressRoute) provide more predictable pricing than public internet egress. Architect applications to minimize unnecessary data movement between services.
3
Security tooling and compliance expansion
A new security perimeter requires new security tools
What it is Cloud environments require a different security model from on-premises infrastructure. The shared responsibility model means organizations are responsible for securing their data, applications, access controls, and configurations, but none of the physical infrastructure. Cloud Security Posture Management (CSPM) tools, Cloud-Native Application Protection Platforms (CNAPP), Identity and Access Management at cloud scale, key management services, secrets management, and extended SIEM integrations are all costs that don't exist in a data center environment and need to be budgeted as new recurring expenditures. For organizations in regulated industries (healthcare, financial services, government), compliance tooling and audit evidence collection in the cloud adds further costs.
Why it gets underestimated Security tools for the cloud are budgeted separately from the migration project. Migration teams estimate compute and storage. Security teams add tooling requirements after migration planning is complete, often to find the budget is already set.
ROI impact Recurring. Security tooling costs scale with the number of cloud accounts, services, and resources being monitored. IBM's Cost of a Data Breach research found that organizations using extensive security automation save an average of $1.9 million per breach, making security tooling investment economically justified, but it must appear in the business case regardless.
How to model it Work with the security team during migration planning, not after. Identify which security controls currently provided by on-premises infrastructure must be replaced with cloud-native equivalents. Budget for CSPM, IAM governance, and secrets management as baseline recurring costs. For compliance requirements, engage with GRC specialists before finalizing the cloud architecture.
How to reduce it Use cloud-native security services before purchasing third-party tools, as native services are often included in support tiers or have more transparent pricing. Consolidate security tooling on a single platform where possible rather than running separate point solutions for each function. See TechRadiant's guide to compliance automation for how teams reduce security and compliance overhead.
4
Observability, logging, and monitoring costs
Cloud generates far more data than on-premises, and you pay for all of it
What it is Distributed cloud environments generate significantly more observability data than centralized on-premises infrastructure. Logs, metrics, traces, and security events from dozens of cloud services, containers, serverless functions, and managed databases all need to be collected, stored, indexed, and queried. Cloud-native observability services (AWS CloudWatch, Azure Monitor, Google Cloud Operations) charge for log ingestion volume, metric storage, dashboard queries, and retention periods. Third-party observability platforms (Datadog, New Relic, Grafana Cloud, Splunk) add per-host or per-GB licensing on top of cloud costs.
Why it gets underestimated On-premises monitoring is often a fixed-cost tool with unlimited data retention within local infrastructure. Cloud-native monitoring is consumption-priced. Teams that simply move their monitoring practices to the cloud without adjusting log verbosity, retention policies, and sampling rates can see observability costs become a meaningful percentage of their total cloud spend.
ROI impact Recurring and variable. Observability costs grow with application complexity and traffic volume. They can surprise teams that never paid for monitoring per GB of log data previously.
How to model it Estimate log volume per service based on current logging verbosity and expected event rates. Model retention requirements against provider pricing. Budget separately for security event monitoring (often priced differently from application logs). Run an observability cost estimate before finalizing tool selection.
How to reduce it Audit log verbosity before migration and reduce DEBUG-level logging to appropriate environments only. Implement log filtering and sampling for high-volume sources. Use tiered storage for older logs rather than keeping everything in hot storage. Establish a defined log retention policy based on compliance requirements rather than defaulting to indefinite retention.
5
Overprovisioning and idle resource waste
The cloud makes it easy to create. It makes it easy to forget too.
What it is Cloud infrastructure is provisioned in minutes and billed continuously. Development and staging environments created for migration testing, performance tuning, and validation are often left running after their purpose is served. Instances are sized based on peak estimates rather than measured usage. Storage volumes are created and forgotten. Compute resources that run 24/7 for workloads that only need 8 hours of operation per day burn twice what they should. A Flexera survey found that organizations estimate they waste approximately 32% of their cloud spend, a figure that may be higher in the months following migration when governance practices haven't been established yet.
Why it gets underestimated On-premises infrastructure that is idle still costs the same, power, space, depreciation. Cloud idle infrastructure costs are variable and therefore feel controllable, but without governance they aren't controlled. The same engineers who are focused on getting workloads migrated are rarely also focused on cost governance during the migration period.
ROI impact Recurring and immediately controllable. Waste that isn't addressed in the first 90 days post-migration compounds into the baseline spend and gets treated as normal. Organizations that implement FinOps practices before or immediately after migration typically identify significant savings relative to their initial cloud spend.
How to model it Apply a realistic utilization assumption to all compute estimates rather than pricing at 100% of provisioned capacity. Include a FinOps and right-sizing budget in the post-migration cost plan. Model a 30-day and 90-day optimization review as a planned activity with associated engineering time.
How to reduce it Implement cloud cost alerts from day one. Establish a tagging policy before migration so every resource is attributed to a team and workload. Schedule automated shutdown of non-production environments outside working hours. Right-size instances based on actual usage data at 30 and 90 days post-migration. Use reserved or committed-use pricing for stable workloads after usage patterns are established.
6
Cloud-native architectural service costs
Cloud bills are the sum of many services, not one infrastructure line item
What it is A cloud-native architecture that replaces on-premises infrastructure typically introduces managed services that didn't exist in the original environment: managed relational databases, managed Kubernetes services, load balancers, NAT gateways, API gateways, object storage, CDN, secrets management, key management, managed message queues, and managed container registries. Each adds a line item to the monthly bill. Individually they appear inexpensive. In aggregate they constitute a material part of the cloud operating cost that rarely appears in the initial estimate, which focused on virtual machine pricing.
Why it gets underestimated Migration business cases price what will replace on-premises servers. They don't price the ancillary services that a cloud-native architecture requires to operate those servers reliably and securely. NAT gateway costs, load balancer costs, and managed database costs are architectural decisions with recurring financial consequences that don't appear until the architecture is finalized.
ROI impact Recurring. These costs grow with the number of services, regions, and environments. A multi-account, multi-region architecture (common in enterprise cloud deployments) multiplies ancillary service costs accordingly.
How to model it Create a target architecture diagram before finalizing the cost model. Use cloud provider pricing calculators to estimate every managed service in the target architecture, not just compute and storage. Price the architecture in each region and environment (production, staging, DR) separately.
How to reduce it Evaluate whether managed services provide sufficient operational benefit to justify their cost compared to self-managed alternatives. Consolidate environments where it is architecturally safe to do so. Avoid replicating full production architectures in development environments.
7
Skills, hiring, and long-term cloud operating capability
Migration labor and ongoing operations require different skills
What it is Cloud migration requires expertise in cloud architecture, infrastructure as code, DevOps practices, cloud networking, cloud security, and FinOps. Long-term cloud operations require a different and ongoing version of those same skills. Organizations typically underestimate both. Migration consultants address the project-phase expertise gap, but they don't transfer enough capability to the internal team to operate the environment confidently after they leave. The World Economic Forum and major cloud providers consistently cite cloud skills gaps as a primary barrier to successful cloud adoption.
Why it gets underestimated Migration labor is visible and bounded. It shows up as consulting fees or project team salaries in the migration budget. The ongoing capability gap is less visible: the internal team that struggled to manage on-premises infrastructure doesn't automatically become proficient in cloud operations simply because the workloads moved.
ROI impact Both one-time (training investment, productivity dip during transition) and recurring (ongoing capability development, potentially higher cloud costs from under-optimized operations). Kagool's framework notes a typical 15-20% productivity dip during the first three months as teams adapt.
How to model it Budget training separately from migration labor. Include a productivity factor for the transition period. Model ongoing cloud operations staffing requirements, including any new roles (cloud operations engineer, FinOps analyst, cloud security engineer) that didn't exist in the on-premises model.
How to reduce it Invest in cloud certification and training for internal engineers before migration begins rather than after. Require knowledge transfer as a contractual deliverable from migration consultants. Consider cloud operations managed services as an interim capability bridge while building internal expertise.
8
Software licensing changes and BYOL complexity
Existing licences often don't transfer to cloud environments
What it is Enterprise software licenses often have cloud-specific terms that differ from on-premises terms. Some commercial databases, middleware platforms, and enterprise applications require separate cloud-use rights or carry different pricing in cloud environments. Bring-Your-Own-License (BYOL) arrangements exist but require careful validation against specific vendor terms. Some virtualization licensing that covers on-premises workloads does not automatically extend to all cloud deployment models. Discovering licensing gaps after migration can require either purchasing cloud-use rights retroactively or replacing software with cloud-native alternatives mid-programme.
Why it gets underestimated Licensing reviews are treated as a procurement exercise rather than a migration prerequisite. The engineers planning the migration focus on technical compatibility. The licensing terms that govern cloud deployment rights sit in contracts that may not be easily accessible or interpreted without vendor engagement.
ROI impact Can be significant and one-time if retroactive cloud-use rights must be purchased. Ongoing where cloud pricing for a product differs materially from the on-premises licensing model.
How to model it Conduct a software license audit specifically focused on cloud deployment rights before migration planning is complete. Engage major vendors (database, middleware, commercial OS) to confirm cloud coverage under existing agreements. Model replacement costs for any software that cannot be licensed cost-effectively in cloud environments.
How to reduce it Evaluate cloud-native managed database alternatives where commercial database licensing in cloud is prohibitive. Leverage existing enterprise agreements (AWS, Azure, or Google Cloud) that may include credits or hybrid benefit provisions. Negotiate license amendments before migration rather than discovering gaps after.
9
Backup, disaster recovery, and business continuity
Cloud migration doesn't eliminate DR costs, it changes their shape
What it is Backup and disaster recovery in the cloud involves cloud storage costs for backup data, cross-region replication for multi-region DR architectures, managed backup services, the cost of maintaining a secondary DR environment (either warm or hot), and periodic DR testing. For organizations with existing on-premises DR infrastructure, cloud migration doesn't automatically reduce DR costs, it replaces one set of DR costs with a different set. For organizations that didn't have formal DR, cloud migration often prompts the right decision to implement it properly, but adds a previously absent cost line.
Why it gets underestimated Migration business cases price the primary cloud environment. DR environments are treated as a separate project. In practice, designing DR into the architecture from the start is significantly cheaper than retrofitting it after the primary migration completes.
ROI impact Recurring. DR environments running continuously (warm DR) incur significant ongoing cost. The correct model accounts for backup storage growth over time, as data volumes in cloud environments often grow faster than anticipated.
How to model it Define RTO and RPO requirements before modeling DR costs. Price backup storage at expected data volumes, including growth. Model cross-region replication costs for primary data. Include DR test execution costs as a recurring operational expense. See TechRadiant's guide to IT resilience and business continuity planning for the full DR cost framework.
How to reduce it Use tiered storage for backup data (moving older backups to cheaper cold or archive tiers). Design DR using cloud-native failover capabilities (auto-scaling, multi-AZ, read replicas) rather than maintaining a full duplicate environment. Match DR investment to workload criticality rather than applying the same DR architecture to every application.
10
Multi-cloud and hybrid-cloud operational complexity
Every additional environment multiplies operational costs
What it is Organizations that operate across on-premises infrastructure, AWS, Azure, and Google Cloud simultaneously face compounded costs that don't exist in single-environment deployments. Security tooling must work across every environment. Monitoring and observability platforms must integrate with all providers. Networking must connect every environment reliably and securely. Engineering teams must maintain proficiency in multiple cloud platforms. Cost visibility and governance must span all clouds. Skills requirements multiply. Tooling often doesn't integrate seamlessly between providers, requiring additional investment in integration or management platforms.
Why it gets underestimated Multi-cloud is often the result of tactical decisions: one business unit adopted AWS, another adopted Azure, and a third uses Google Cloud for specific AI workloads. The aggregate operational complexity of managing all three is rarely modeled as a cost when individual decisions are made.
ROI impact Recurring and growing. The marginal cost of adding a third cloud platform is higher than the marginal cost of staying on one. Multi-cloud operational complexity is one of the most consistent causes of cloud cost overruns in organizations beyond mid-market scale.
How to model it Model the additional tooling, skills, and management overhead of each additional environment. Be specific about whether multi-cloud is a deliberate strategy with modeled benefits or an accumulation of uncoordinated decisions.
How to reduce it Define a primary cloud platform and treat others as exceptions that require explicit justification. Standardize tooling choices across environments where possible. Consolidate workloads onto fewer platforms when it makes architectural and business sense.
11
Vendor commitment and reserved capacity miscalculation
Committing too early or to the wrong resources locks in the wrong cost
What it is Cloud providers offer significant discounts (typically 30-72% depending on provider, service type, and commitment term) for reserved or committed-use capacity compared to on-demand pricing. These discounts are attractive. But they require organizations to commit to specific resource types in specific regions for 1 or 3 years. If workloads change, migrate between regions, or are replaced by managed services during that commitment period, the organization may be paying for capacity it no longer uses. Organizations that purchase commitments prematurely, before actual usage patterns are understood, often end up with commitment waste alongside on-demand charges for new workloads.
Why it gets underestimated Reserved pricing looks like an obvious win. The commitment risk is less visible, particularly for organizations purchasing commitments during or immediately after migration before usage patterns have stabilized.
ROI impact Recurring until commitment expires. Unused committed capacity is a direct write-off against cloud ROI.
How to model it Model reserved capacity purchases only for workloads where usage is stable and well-understood. Budget for on-demand pricing for workloads during the first 6-12 months post-migration. Phase commitment purchases after usage data is available.
How to reduce it Wait at least 90 days post-migration before purchasing significant reserved capacity. Use Savings Plans (AWS) or Azure Reservations with compute-level flexibility rather than instance-level commitments where possible. Manage reserved capacity as an ongoing FinOps practice rather than a one-time purchase.
12
Post-migration optimization as a permanent programme
Migration is go-live. Optimization is the ongoing work after it.
What it is Cloud cost optimization is not a post-migration project with a defined end date. As usage grows, applications evolve, new services are adopted, and teams change, the cost profile of a cloud environment drifts. Rightsizing becomes stale within months as usage patterns change. Reserved capacity decisions must be revisited at renewal. Storage lifecycle policies need to be reviewed as data accumulates. New cloud services may offer better price-performance than what was selected at migration time. Organizations that treat optimization as a one-time exercise after migration typically see cloud costs grow faster than their workloads grow.
Why it gets underestimated Migration business cases model a static end state. Cloud environments are not static. Usage grows, architectures evolve, and costs drift. The business case that was presented to the board modeled a point in time, not a trajectory.
ROI impact Recurring and growing. The cost of not doing ongoing optimization is higher cloud spend relative to workload value. The cost of doing it is staffing a FinOps function or equivalent engineering time.
How to model it Budget for a FinOps function (dedicated FinOps analyst, shared engineering time, or FinOps tooling) as a recurring operating cost of the cloud environment. Model cloud costs at different growth scenarios to understand how the bill scales with workload growth.
How to reduce it Implement cloud cost governance from day one rather than treating it as a post-migration activity. Use FinOps tooling (cloud-native cost management consoles, or dedicated FinOps platforms) to maintain ongoing visibility. Establish a regular cost review cadence across engineering, finance, and leadership.

One-time vs recurring cost classification

Understanding which costs are incurred once and which become permanent operating expenses is critical for building a multi-year ROI model. The first-year cost of cloud migration is always the most expensive. The question is how the cost profile changes in years two and three.

Cost category One-time Recurring Variable Often underestimated
Assessment and discovery✓✓
Application refactoring✓sometimes✓
Migration labor✓✓
Data egress (migration phase)✓✓✓
Data egress (ongoing)✓✓✓
Cloud compute and storage✓✓✓
Security tooling (CSPM, CNAPP)✓✓✓
Observability and logging✓✓✓
Overprovisioning / idle waste✓✓✓
Skills and training✓partial✓
Software licensing changes✓✓✓
Backup and DR✓✓✓
FinOps and optimization✓✓
Commitment miscalculation✓if renewed✓
Multi-cloud overhead✓✓✓

The real cloud migration TCO model

A complete Total Cost of Ownership model for cloud migration has three components. The numbers in these formulas are illustrative structures, not universal benchmarks. Organizations should populate them with figures derived from their specific architecture, workload characteristics, and vendor agreements.

Component 1, Total migration cost (one-time)
Assessment + architecture planning + migration labor + consulting fees + data movement costs + temporary parallel infrastructure + application refactoring and remediation + testing and validation + training
Component 2, Annual cloud operating cost (recurring)
Compute + storage + databases + networking + data egress + security tooling (CSPM, IAM, SIEM) + observability and logging + backup and DR + cloud support tier + FinOps and optimization + cloud operations staffing + software licensing
Component 3, Business impact (often excluded)
Application downtime during migration + productivity loss during transition + migration-related risk events + performance impact on customer-facing systems
Real ROI = (Business benefits + operational improvements) minus (Total migration cost + cumulative cloud operating cost over evaluation period)
What "business benefits" should include in the ROI model
Cloud migration benefits that belong in the ROI model include: elimination of hardware refresh cycles (capital cost), reduction or elimination of data center facility costs (power, cooling, space), faster application deployment cycles (developer productivity), improved uptime through cloud SLAs, ability to scale without upfront capital, access to managed services that reduce operational labor, and reduced time to market for new products. These benefits are real but should be projected conservatively and realized incrementally over multiple years, not assumed from day one.

How a $5M migration can become a $7M project

The following is a hypothetical example intended to illustrate how migration budgets expand when initially excluded cost categories are added. The figures are illustrative, not industry benchmarks. Real project costs depend on organizational size, workload complexity, migration strategy, and operating model.

Hypothetical: Initial estimate vs revised estimate
This example is illustrative only and should not be used as a benchmark for your organization's migration planning.
Cost category Initial estimate Revised (after full assessment) What changed
Cloud infrastructure (annual) $3,000,000 $3,200,000 Added managed databases, NAT gateways, and observability services not in initial estimate
Migration labor $1,000,000 $1,400,000 Application remediation work discovered during discovery added 3 additional engineering months
Consulting and tools $1,000,000 $1,100,000 Extended consulting engagement due to schedule extension
Application refactoring not included $400,000 Three legacy applications required significant remediation before cloud deployment
Security tooling (annual) not included $200,000 CSPM, IAM governance, and expanded SIEM integration required
Temporary parallel infrastructure not included $150,000 Six months of dual-environment running during phased migration
Training and capability development not included $80,000 Cloud certification programme for eight engineers
Schedule extension costs not included $120,000 Two-month programme extension due to application remediation complexity
Total $5,000,000 $6,650,000 33% higher than original estimate due to categories not included in initial planning

The point of this hypothetical is not that migrations inevitably cost 33% more. It is that the categories excluded from the initial estimate in this example (refactoring, security tooling, parallel infrastructure, training, schedule extension) are not unusual or exceptional. They are predictable. Including them in the planning model doesn't make the migration more expensive, it makes the business case more accurate.

Lift-and-shift vs modernization: which has better ROI?

The migration strategy chosen for each application has the largest single influence on the financial outcome. The right answer depends on the specific workload, not on a universal preference.

Rehost
Lift-and-shift
Lower initial cost. Less engineering effort before migration. Faster to execute. Suitable for deadline-driven scenarios.
May carry inefficient architectures into the cloud, producing 20-30% higher ongoing operating costs than a refactored equivalent. Doesn't access cloud-native capabilities. Often requires a follow-up modernisation project that adds cost.
Replatform
Lift, tinker, shift
Middle ground. Targeted optimizations during migration. Switch to managed database services without rewriting the application. Better operating cost than pure rehost. Meaningful improvement without full refactor scope.
Requires more upfront engineering than a lift-and-shift. Requires a clear decision about which optimizations are worth doing now versus deferring.
Refactor
Modernisation
Best long-term economics. Cloud-native architecture, auto-scaling, managed services, better utilization. Better developer productivity after migration. Eliminates technical debt.
Highest upfront cost and engineering effort. Longest time to value. Requires engineering capacity and cloud expertise that may need to be developed or hired.

The economics comparison that matters is not migration cost but total cost over the intended lifespan of the workload. A lift-and-shift that costs $200K less to migrate but runs $150K per year more in cloud costs becomes more expensive than a refactor after approximately 18 months, before accounting for the eventual modernisation cost that may still be required. The correct strategy depends on the workload's expected lifespan, the engineering capacity available, the migration deadline, and how important cloud-native capabilities are to the application's future development.

The FinOps connection

FinOps is the practice of bringing financial accountability to cloud spending. It involves real-time cost visibility, cost allocation by team and workload, budgeting and forecasting, rightsizing, commitment management, and engineering accountability for the costs generated by engineering decisions. The FinOps Foundation defines it as a cultural practice that enables cross-functional teams to make business trade-offs between speed, cost, and quality.

The mistake most organizations make is treating FinOps as a post-migration activity, something to implement once the cloud bill surprises arrive. By the time the first large invoice lands, habits have been established, resources are provisioned at the wrong sizes, and costs have compounded for months without visibility.

📊
Cost visibility before it's a crisis
Implement tagging policies and cost allocation dashboards before migration. Every resource should be attributable to a team and workload from day one, not retroactively.
⚖️
Rightsizing as a continuous practice
Cloud rightsizing is not a one-time post-migration activity. Usage patterns change as applications evolve. Rightsizing reviews should run on a defined cadence.
📅
Commitment management
Reserved capacity and committed-use discounts require active management. Commitments should be purchased based on measured usage, not estimated usage, and reviewed at renewal.
🎯
Unit economics
Tracking cloud cost per unit of business value (cost per transaction, cost per customer, cost per API call) connects cloud spending to business outcomes and makes ROI measurement meaningful.

The FinOps Foundation's framework provides a structured approach to building cloud cost management practices. Their resources and state-of-FinOps research are available at finops.org and are relevant to any organization planning or executing a cloud migration.

How to build a more accurate cloud migration ROI model

1
Inventory all workloads with their current resource utilization
Capture what exists, what it runs on, and what it actually uses. Utilization data from production monitoring over 30-90 days is far more accurate than provisioned capacity as a sizing input.
2
Measure current fully-loaded TCO, not just infrastructure
Include hardware amortization, data center space, power and cooling, hardware maintenance, OS and software licensing, security tooling, backup, networking, and staff. Most organizations discover their on-premises TCO is higher than their infrastructure line items suggest.
3
Classify every application by migration strategy
Sort applications into Retire, Retain, Rehost, Replatform, Refactor, and Replace categories. The Refactor and Replatform categories require engineering estimates. The Retire category reduces migration scope and cost. Each strategy has a different cost profile and different ROI trajectory.
4
Model cloud consumption for the target architecture, not just compute
Price every service in the target architecture including managed databases, load balancers, storage tiers, data transfer, security services, observability, and backup. Use current provider pricing documentation. Price each environment (production, staging, DR) separately and in each required region.
5
Add all migration-phase costs explicitly
Include assessment, consulting, migration engineering labor, temporary parallel infrastructure, data movement, application remediation, testing, and training. Treat each as a named line item rather than a contingency assumption.
6
Model growth over a 3-year horizon
Cloud costs grow with usage. Model cloud spend at year one, year two, and year three under realistic growth assumptions. Include new workloads, data growth, and traffic growth. A migration that looks ROI-positive at today's workload may look different at 2x growth if cloud costs scale faster than expected.
7
Add contingency based on migration complexity
Kagool's enterprise framework notes that a 20% contingency is standard for large-scale migrations with significant legacy complexity. The appropriate figure depends on how well-understood the environment is. Simple rehost migrations of modern applications require less contingency than complex re-architecting of legacy monoliths.
8
Recalculate ROI under best-case, base-case, and worst-case scenarios
The strongest migration business cases don't promise a specific outcome. They identify which assumptions most affect the financial result and model what happens when those assumptions vary. Presenting three scenarios to the board produces more honest and robust approval decisions than presenting a single optimistic projection.

For cloud and DevOps agencies who have built rigorous cloud migration cost models for enterprise environments, TechRadiant's verified cloud and DevOps agency index covers teams evaluated on documented delivery outcomes.

Planning a cloud migration?

Find cloud consultants verified on real delivery and cost outcomes

TechRadiant verifies cloud and DevOps agencies on documented migration outcomes. Find a team with experience building realistic cloud migration business cases and delivering on them.

Browse verified cloud agencies → Share your migration brief

Questions executives should ask before approving a migration

These questions are designed to identify gaps in a migration business case before the project is approved. A business case that can answer all of them with specificity is materially more credible than one that cannot.

1
What costs are explicitly included in this estimate, and what is explicitly excluded?
A complete migration business case names its inclusions and exclusions. Any estimate that doesn't acknowledge what it excludes is implicitly assuming those costs are zero.
2
Has every application been assessed for migration strategy, and are refactoring costs included in the estimate?
A lift-and-shift estimate that ignores applications requiring significant remediation is incomplete.
3
Are we modeling the full target cloud architecture cost, including security, observability, databases, networking, and backup, not just compute and storage?
Cloud bills are the sum of many services. Pricing only the instances dramatically underestimates steady-state operating costs.
4
What are the assumptions about workload utilization, and are they based on measured data or estimates?
Utilization assumptions that overstate cloud savings are the most common source of ROI projection failure.
5
What happens to the ROI model if the migration takes twice as long as projected?
Schedule extensions mean extended parallel infrastructure costs, extended consulting fees, and delayed realization of cloud benefits.
6
Has the ROI been modeled at year one, year two, and year three with realistic growth assumptions?
A migration that delivers ROI at today's workload may not deliver ROI at 2x workload if cloud costs scale unfavorably.
7
Who owns cloud cost optimization after migration, and what is the governance model?
Without an explicit owner and a defined FinOps practice, cloud costs drift upward without accountability.
8
What is the payback period under the base-case scenario, and when does it become positive under the worst-case scenario?
A board approval decision should include explicit awareness of the payback horizon and the assumptions that determine it.
9
Are software licensing costs in the cloud explicitly reviewed and confirmed?
License surprises discovered post-migration are expensive and disruptive to address.
10
Which assumptions, if wrong, would cause the ROI projection to fail?
Identifying the key sensitivities allows the board to assess risk rather than approve a single optimistic scenario as if it were a forecast.

Cloud migration ROI checklist

Before migration

  • Inventory all workloads including current utilization, not just provisioned capacity
  • Calculate current fully-loaded on-premises TCO including facilities, power, staff, and licensing
  • Classify every application by migration strategy with engineering estimates for refactoring scope
  • Model the complete target architecture cost including all managed services, not just compute
  • Estimate migration labor including internal engineering time, not only consulting fees
  • Budget for temporary parallel infrastructure during the migration window
  • Identify and model data egress costs during the hybrid transition period
  • Conduct a software license audit specifically confirming cloud deployment rights
  • Include security tooling, observability, backup, and DR as explicit recurring cost categories
  • Budget for skills development and plan for a transition-period productivity dip
  • Run ROI calculations at best-case, base-case, and worst-case utilization assumptions
  • Add appropriate contingency based on legacy complexity and dependency risk
  • Define who owns cloud cost governance after migration before the project starts

During migration

  • Track migration spending in a separate cost center from operating cloud costs
  • Monitor actual cloud consumption against modeled estimates every two weeks
  • Validate discovered application dependencies against initial assessment assumptions
  • Track schedule against plan and recalculate budget impact of any extensions
  • Validate application performance in cloud against on-premises baseline

After migration

  • Implement FinOps and cost allocation from day one, not after the first bill surprise
  • Right-size instances based on actual usage data at 30 and 90 days post-migration
  • Monitor observability and security tooling costs against budget
  • Establish a quarterly cloud cost review cadence involving engineering and finance
  • Purchase reserved or committed-use capacity only after usage patterns are confirmed
  • Track cloud cost per unit of business value (unit economics)
  • Recalculate migration ROI at 6 months and 12 months against original projections
  • Document which assumptions from the original business case proved accurate

Cloud migration doesn't destroy ROI. Poor cost modeling does. Organizations that migrate successfully and hit their ROI projections aren't the ones that found a cheaper cloud. They are the ones that built a business case that included all the costs, modeled realistic scenarios, started FinOps before migration rather than after, and treated optimization as a permanent programme rather than a one-time cleanup. The cloud can provide genuine economic and operational benefits. Realizing them requires accounting for the full cost of achieving them.