Lift-and-shift cloud migration costs for enterprises

The migration bill doesn’t end at cutover. Market offers for cloud migration projects span $240,000 to $500,000,000, a broad range that reflects how much scope, workload complexity and post-migration work can vary. The hidden costs of lift and shift cloud migration often surface later, when oversized resources, parallel operations and inherited inefficiencies continue to drive spending.

A fast move can be the right way to relocate workloads, especially when changing application architecture isn’t practical. But moving systems with little or no change can also carry their existing resource demands into a cloud environment where ongoing usage is billed differently. Flexera’s 2026 State of the Cloud report estimates wasted cloud spend at 29 percent of total enterprise cloud budgets.

Understand what shapes the initial migration budget, which costs can rise after cutover, and how rightsizing, cost visibility, and selective modernisation can improve spending control. This guide explains the main cost drivers and the decisions that help enterprises plan for cloud value beyond the move itself.

What is the average cost of a lift-and-shift cloud migration for an enterprise?

There is no reliable enterprise-wide average: workload count, dependencies, licensing, labour, and migration approach all shape total project cost. To identify and reduce the hidden costs of lift and shift cloud migration, inventory applications, compare rehosting with refactoring, measure actual usage, and assign spending ownership before migration.

Account for both the initial move and the cost of running workloads afterwards. Cloud bills can exceed on-premises equivalents in the first year when workloads move without optimisation, so compare total cost of ownership over time, not just the migration budget.

Rehosting and Refactoring Cost Differences

Rehosting moves an application with little or no change, while refactoring changes its code or architecture for cloud operations. Rehosting can limit initial engineering work, but it may carry existing inefficiencies into the cloud and leave teams maintaining infrastructure that was not designed for it.

Refactoring can require more upfront work, yet refactored applications can run 30 to 50 percent cheaper in monthly cloud spend than lift-and-shift equivalents. The higher upfront cost typically reaches break-even in 18 to 30 months. Compare those costs with expected workload life, licensing, operational effort, and the value of faster migration before selecting an approach.

For SAP workloads, SAP data migration planning can support a structured assessment of applications and dependencies before the move.

Post-Migration Right-Sizing

Right-sizing matches cloud compute, storage, and network resources to observed workload demand. It matters because one-to-one transfers can leave 75 to 85 percent of cloud compute capacity idle and billed.

Use 90 days of on-premises CPU, memory, and IOPS data to inform pre-migration sizing, then compare cloud usage with actual performance after cutover. Pre-migration rightsizing can reduce instance count by 30 to 40 percent. Keep a 20 percent headroom buffer above actual utilization when sizing instances, then revisit capacity as demand changes.

Cloud providers may bill resources by the minute or hour, so oversized instances can keep incurring charges even when lightly used. Schedule reviews, remove idle resources, and assign responsibility for optimisation rather than treating cutover as the finish line.

Labor and Compliance Considerations

Labour costs cover the people and time needed to assess dependencies, migrate applications, test performance, and resolve issues after cutover. In the US, project scope, legacy-system complexity, team expertise, and parallel operations all influence the effort required.

Compliance work also affects the migration plan. Identify the obligations that apply to each workload, then account for security reviews, access controls, logging, backups, and recovery planning. GDPR and NCA ECC may apply in relevant contexts, so map requirements to the data and jurisdictions involved instead of assuming one set of controls covers every application.

Keep labour and compliance work visible as project costs, not unassigned overhead. A migration plan that assigns owners to assessment, validation, and remediation gives finance and technical teams a clearer view of the total effort.

Cloud pricing models also shape ongoing costs: on-demand usage can fluctuate with consumption, while reserved capacity can make spend more predictable for stable workloads. The FinOps Foundation recommends cost allocation, tagging, visibility, and clear ownership to connect cloud charges with accountable teams. Flexera’s 2026 State of the Cloud report estimates wasted cloud spend at 29 percent of total enterprise cloud budgets.

Build a cost baseline before migration, then compare actual cloud charges with it after each workload moves. Track compute, storage, licensing, and data movement separately. This makes cost growth easier to trace to a particular application or operational decision.

How to Optimize Costs After Migration?

Overprovisioning and idle resources raise costs because cloud billing continues while capacity is allocated, even when workloads use little of it. Find waste by comparing resource consumption with performance, removing obsolete migration artefacts, and assigning owners to cloud spending.

Review usage, inventory, and billing data together. Then use tags, budgets, and alerts to make cost changes visible across teams.

Idle Resources and Migration Artifacts

Idle resources and migration artefacts are cloud assets left unused or no longer needed after workloads move. Inactive virtual machines, outdated snapshots, and temporary storage can continue generating charges.

Compare the active workload inventory with deployed resources, then remove assets that no longer support a live application. For example, a temporary migration copy or test virtual machine can remain after its purpose ends. Apply ownership tags during migration so teams can trace each resource to a workload and decide whether to retain or delete it.

Over-Provisioned Cloud Resources

Over-provisioning means allocating more compute, memory, or storage than an application needs under its actual operating conditions. Enterprise on-premises server fleets average 15 to 25 percent CPU utilization, so moving their full capacity into a cloud environment can preserve excess rather than adapt to demand.

An oversized cloud virtual machine running at 10% utilization costs the same as one running at 90%. Review utilization and performance together: low CPU alone doesn’t prove a resource can be reduced if memory, storage, or application response times are constrained. Cloud environments can scale dynamically, but applications that aren’t adapted to elasticity may keep consuming fixed capacity.

Resource Right-Sizing

Right-sizing adjusts resource types and capacity to match observed application demand. It matters because organizations may overspend by 20-50% on cloud resources through poor sizing and limited ongoing visibility.

Compare consumption trends with workload performance, then tune instance types, network setups, and storage levels. Use autoscaling for workloads with changing demand, and schedule tasks that don’t need continuous compute. Savings after lift-and-shift typically materialize only after 6 to 18 months of rightsizing and workload optimization, making repeated reviews essential.

Make cost ownership part of the operating structure. The FinOps Foundation recommends cost allocation, tagging, visibility, and clear ownership to help teams understand spending and responsibility. Apply consistent tags for application, team, and environment, then use budgets and billing alerts to flag unusual consumption before it becomes an ongoing pattern.

Cost drift often appears within the first 60-90 days after migration, so establish storage, tagging, budgets, and alert controls early. Review spending reports alongside resource performance, and set policies for unused assets and unusual charges. Cloud cost optimization belongs in the migration plan, not as work deferred for six months.

For teams aligning cloud infrastructure management with cost visibility, a cloud cost conversation can help frame the next steps.

Storage growth from backups, snapshots, logs, and duplicate data

Overlooked charges can include compute, persistent storage, backup copies, snapshots, log retention, and data transfer. Networking, egress, and inter-region transfer fees depend on the cloud provider’s pricing model, transfer routes, data volume, and how often systems exchange information.

For an enterprise, the key is to trace storage growth and data movement by workload. A database copied for migration, retained as a rollback point, and then backed up again can occupy several separate storage locations.

Backups, Snapshots, and Duplicate Data

Backups and snapshots preserve recovery points, while duplicate data creates additional copies of the same information. Either can remain in cloud infrastructure after its original purpose has passed, adding recurring storage use alongside the live application.

Map each backup to its source system, retention purpose, and owner. Then identify snapshots created for migration testing or rollback and remove those no longer needed. For example, a team can compare production data with retained migration copies to decide which support recovery and which are obsolete.

Logs need the same discipline. Set retention according to operational and compliance needs, and separate frequently accessed logs from records kept for reference. Moving rarely accessed data to less expensive storage tiers and removing outdated backups can reduce long-term storage costs.

Data Movement and Network Paths

Data movement can generate transfer and egress charges when information travels between availability zones or external systems. For example, a cloud application that regularly sends records to an external analytics platform creates ongoing transfer costs beyond the initial migration.

Map data flows across the application architecture before moving workloads. Record which systems exchange data, where each endpoint runs, and whether traffic crosses zones or leaves the cloud environment. This can reveal temporary migration paths that remain active after cutover, such as a cloud database continuing to replicate to an on-premises data centre.

Tracking Storage and Transfer Exposure

Review storage and network consumption by application instead of treating the cloud bill as one total. Tag resources by workload and environment, then compare backup volumes, snapshot inventories, log retention, and transfer patterns in regular cost reports.

During migration, temporary network routes can support data synchronisation and validation. Retire them when the relevant migration activity ends, while preserving connections required for production. Document each route’s purpose, owner, and data exchanged to link recurring transfer charges to business activity.

Cloud transfer charges have no single enterprise-wide amount: provider pricing, route, volume, and frequency determine the bill. Include data movement in the migration cost model, then monitor it alongside storage growth. The Board of Governors of the Federal Reserve System notes that migration budgets may need to include infrastructure and support costs in addition to migration itself.

Compliance and security validation costs

Security and compliance work belongs in the migration scope, not as an optional post-cutover task. A lift-and-shift can carry existing vulnerabilities into the cloud, while cloud operations involve responsibilities that differ from on-premises practices.

Include vulnerability scans, patches, access controls, logging, backups, compliance reviews, and recovery planning. These activities identify gaps before migration and help validate protection after workloads move.

Security Validation and Remediation

Scan applications planned for migration for vulnerabilities, then address findings through patches or other remedies. For example, copying a legacy application with an outdated component unchanged can carry that exposure into its new environment.

Review controls, user access, backup arrangements, logging, compliance requirements, and recovery plans for each migrated application. The shared responsibility model matters too: on-premises security practices may not provide sufficient protection in a cloud environment. Allocate time for validation and remediation in the migration strategy instead of leaving the work to operations after cutover.

Compliance and Licensing Reviews

Compliance requirements depend on the workload, data, and applicable jurisdictions. GDPR is relevant to cloud migration, including in regulated industries and government; NCA ECC applies in certain regions. Map each application’s data and operating context to relevant requirements, then assess the migration plan and cloud infrastructure against them.

Licensing can create a separate compliance exposure. Cloud software terms may differ from on-premises terms, and some vendors charge a premium for cloud environments. Review license rights and restrictions before migration: using software without carefully checking its terms can lead to an audit, penalty, or mandatory renegotiation.

Operational Complexity and Recovery

Lift-and-shift can add operational complexity when teams must maintain applications and back-end infrastructure that were not designed for cloud operations. Include monitoring, incident handling, backup management, and recovery testing in the operating model. Otherwise, ownership may be unclear when a migrated workload fails.

For each application, document who monitors alerts, manages access, reviews logs, and tests recovery. Confirm that backup processes preserve the required data and that recovery plans account for cloud dependencies. Defined responsibilities help teams understand the operational capacity migration requires and where extra processes or ongoing managed IT support services may be needed.

Costing the Validation Work

Build security and compliance validation into the migration budget alongside infrastructure and support. Break out assessment, remediation, access configuration, logging, backup validation, and recovery testing as separate work items. This gives programme leaders visibility into responsibilities instead of treating validation as an undefined final phase.

Make the review repeatable across migration waves: record findings, assigned owners, remediation status, and approval for each application. This creates an evidence trail for internal reviews and helps operations teams inherit workloads with known controls and recovery procedures.

Compute, storage, licensing, and support during overlap

Overlap costs arise when on-premises and cloud environments run together during migration. Enterprise programmes can incur duplicate compute, storage, network, licensing, and support costs across applications.

The Board of Governors of the Federal Reserve System notes that migration budgets may need to include infrastructure and support costs beyond the migration itself.

Post-Migration Software Licensing

Post-migration software licensing means reviewing how vendor terms apply when workloads move from on-premises infrastructure to cloud compute. It matters because cloud licensing can differ from on-premises licensing, and some vendors charge a premium for cloud use.

Review each application’s license terms before scheduling its move. Enterprise software terms may require 30 to 90 days’ notice to adjust before migration. Check permitted hosting environments, license portability, and changes to usage measurement, then include any required adjustment in the migration plan.

Skipping that review can expose an organisation to an audit, penalty, or mandatory renegotiation. Some software restrictions can make lift-and-shift prohibitively expensive or legally impossible, so resolve licensing dependencies before transferring a workload.

Unused Software Licenses

Unused software licences are entitlements that remain paid for after an application or user no longer needs them. During migration, software may remain licensed on-premises while cloud instances require separate or adjusted licensing.

Build a licence inventory by application, environment, and usage before cutover. Compare assigned entitlements with active workloads, then identify licences tied to retired instances, duplicate environments, or users who no longer need access. Do not assume a licence for a data-centre deployment automatically covers the cloud version.

Use migration waves to align licence changes with actual cutover dates. Record which legacy instances remain active and who owns each contract. This helps avoid paying for unused software while preserving licences needed for rollback or parallel testing.

Overlapping Support Costs

Overlapping support costs are the expenses of operating and supporting old and new environments simultaneously. Enterprise migrations have a median parallel-operation period of 4 to 6 weeks per application cluster, with teams maintaining both environments during that window.

For large enterprises, parallel operation can add 30 to 50 percent of annual on-premises costs to the cloud bill for the duration of the migration window. Compute and storage may be duplicated, while network connections, software support, and operational monitoring continue across both sites.

Programs involving hundreds of applications can run parallel environments for 6 to 12 months across the full portfolio. Track each cluster’s cutover, validation, and decommissioning milestones so temporary resources don’t become permanent. The cloud provider may charge by the minute or hour, while premises infrastructure and support continue accruing costs.

Set an owner and retirement date for each legacy server, license, network path, and support arrangement. For a migration plan that accounts for overlap and licensing, discuss your cloud migration requirements.

Kagool: SAP Consulting Services

Kagool helps enterprises assess SAP workloads when migration planning needs to account for dependencies, data movement, licensing, and post-cutover operations. Its SAP Consulting Services and SAP Data Migration Services support organisations evaluating how to move SAP environments while managing technical and operational considerations.

Turn to Kagool when your teams need to shape a migration approach, plan data movement, or connect SAP decisions with a broader cloud strategy. For organisations building on Microsoft platforms, Microsoft Azure and Fabric Solutions can also support the wider data environment.

To discuss your SAP migration requirements, contact Kagool.

Turn migration planning into lasting cloud value

Planning for the hidden costs of lift and shift cloud migration starts with treating migration as a decision about how the business will operate and evolve, not simply where applications run. Define success for each workload, identify who owns the outcomes, and consider how the architecture should adapt as priorities change. This helps teams move beyond completing a transfer towards a cloud environment designed to support durable growth.

Kagool brings together SAP Consulting Services, Microsoft Azure and Fabric Solutions, and Databricks Data Platform Implementation to help organisations align technology choices with business and data priorities. This expertise can connect SAP landscapes, cloud platforms, and future data initiatives within a coherent strategy.

Discuss your goals and constraints with Kagool. Discuss cloud migration with Kagool. A clear direction today can help build more adaptable operations for what comes next.

Frequently Asked Questions

Does lift-and-shift save money compared to staying on-premises?

Not necessarily, especially if you compare only infrastructure bills. A useful comparison includes cloud operating costs and the remaining life of on-premises equipment, typically amortized over a 3 to 5 year lifecycle. Also account for workloads that would need hardware replacement soon. Model both options across a three-to-five-year horizon, using expected demand and operating requirements, rather than treating a lower initial migration effort as proof of long-term savings.

Is lift-and-shift suitable for every application?

No. Some applications depend on legacy middleware, fixed IP addresses, or monolithic structures that can create latency and performance problems in distributed cloud systems. Vendor applications may also have terms that prevent code changes, making rehosting more practical. Consider each application’s dependencies, performance needs, API access, license restrictions, and planned lifespan. An application intended for retirement within the next 12 months is generally a poor migration candidate.

Should Businesses Avoid Lift-and-Shift?

No. Lift-and-shift can be practical when speed matters, architecture changes carry risk, or a supplier restricts application changes. It can also help establish a hybrid cloud deployment while sensitive workloads remain on-premises. The key is not to treat rehosting as the final modernisation strategy. Classify workloads individually, then combine rehosting with selective refactoring where cloud-native capabilities or performance improvements justify further change.

What Other Costs Should Business Leaders Watch?

Look beyond compute to contract changes, engineering effort, validation, and operational support. For example, software license terms may require 30 to 90 days’ notice before migration adjustments. Data movement between availability zones or external systems can also add transfer charges. Assign each cost to a workload and an owner, then compare actual spending with the migration plan. This helps leaders distinguish temporary cutover expenses from recurring costs.

What’s the long-term cost difference between lift-and-shift and refactoring?

Refactoring can cost more upfront, but refactored applications can run 30 to 50 percent cheaper in monthly cloud spend than lift-and-shift equivalents. The higher initial cost typically reaches break-even in 18 to 30 months. Compare those savings with the application’s expected lifespan, business criticality, and engineering effort. If the workload remains inefficient after rehosting, its ongoing costs can outweigh the lower initial migration effort.

When should you choose Modernization?

Choose modernisation when an application needs better cloud performance, operational flexibility, or maintainability, and its business value justifies the additional work. It may be especially relevant when an application remains slow after relocation or fixed resource use prevents it from benefiting from cloud elasticity. Consider selective changes rather than rebuilding everything. For example, an organisation might modernise a database while keeping the application stack on virtual machines.

What are the hidden costs of lift-and-shift cloud migration?

The hidden costs of lift and shift cloud migration usually come from ongoing operations rather than the transfer alone. These may include excess capacity, parallel environments, backups and snapshots, data egress, security remediation, licence changes, and additional support. Assess costs by application: map dependencies, identify who owns each resource, and distinguish temporary migration assets from those required for production. That inventory makes recurring costs easier to identify and manage.

How much does lift-and-shift cloud migration typically cost?

The total depends on application count, dependencies, migration waves, testing, and the work needed to maintain business operations during cutover. Treat this as a market project-cost range, not a quote. A useful estimate separates migration labour and validation from the cloud infrastructure and support costs that continue afterwards.