Rehosted workloads usually preserve the same architecture, operations, and inefficiencies that existed on premises. AWS notes that lift and shift avoids the optimizations that reduce time or money, so savings do not appear automatically. Cost improvement typically comes later, through rightsizing, capacity commitments, spend attribution, and selective modernization after the migration is complete.
Rehosting usually preserves the same consumption pattern that made the workload expensive on premises, so the cloud bill reflects old design decisions rather than cloud-native efficiencies. The biggest miss is treating migration as the end state: lift and shift changes location, not waste. Cloud economics improve when teams actively redesign for elasticity, rightsize capacity, and separate steady-state from burst demand.
Why Lift-and-Shift Rarely Delivers Savings on Its Own
Lift-and-shift moves servers, databases, and supporting services with minimal redesign, which is useful for speed but poor for cost reduction. The workload still carries the same instance sizing, storage footprint, licensing model, uptime assumptions, and operational overhead that existed before migration. In practice, cloud pricing can expose inefficiency more clearly because idle capacity, oversized environments, and always-on services become line-item spend instead of being hidden inside a data center budget.
That is why leaders often overestimate savings when they equate “moved to cloud” with “optimised for cloud.” A migration can reduce facility costs, hardware refresh burden, and some maintenance work, but those savings are often offset by the new infrastructure chargeback model if the workload is left unchanged. The strongest economic gains usually come later, after teams adjust architecture and operations to match actual demand patterns.
In practice, many organisations discover that the migration finished successfully long before the cost problem was actually addressed.
How It Works in Practice
Lifted workloads tend to fail financially for a few repeatable reasons. First, teams carry forward overprovisioned virtual machines and reserve them “just in case,” even when utilisation is low. Second, they keep the same deployment topology, including redundant environments, oversized test stacks, and long-running batch windows that do not need constant capacity. Third, they underestimate cloud-native cost controls such as autoscaling, storage tiering, commit-based discounts, and lifecycle policies.
- Rightsizing matters because cloud charges follow allocated capacity, not only average usage.
- Tagging and cost attribution matter because shared platforms hide which product, team, or environment is consuming spend.
- Modernisation matters because managed services often reduce operational burden, but only when the workload can actually use them.
- Commitments matter because stable baseline demand can usually be priced more efficiently than on-demand consumption.
The migration sequence also matters. If cost optimisation starts before the application is stable, teams often mask performance problems by buying more headroom. If it starts too late, finance sees a cloud bill that looks like an uncontrolled expansion of the data center rather than a controlled transition. The practical goal is to distinguish what must remain always on from what can scale, pause, or move to cheaper storage and compute tiers.
These controls tend to break down when the environment has poor ownership, shared billing structures, or legacy licensing that rewards static capacity over measured consumption.
Common Variations and Edge Cases
Tighter cost control often increases operational discipline, so organisations have to balance speed of migration against the effort needed to realise savings. Not every workload should be modernised immediately, and not every application benefits from aggressive optimisation. A stable internal system with predictable load may justify commitments and modest rightsizing, while a spiky customer-facing platform may need more elasticity and a different cost model.
Some teams also run into edge cases where the cloud is not actually more expensive, but the comparison is flawed. For example, the on-premises baseline may have excluded staffing, depreciation, refresh cycles, or disaster recovery overhead. In other cases, the first cloud bill includes duplicated environments during cutover, which temporarily distorts the economics. Best practice is evolving toward comparing full lifecycle cost, not just monthly infrastructure spend.
The main judgment call is whether a workload is being hosted in the cloud merely because it was migrated there, or because its operating model has been redesigned to take advantage of the cloud.
Risk and Threat Considerations
The main risk is not just overspend, but also cost sprawl that weakens operational control. When rehosted workloads keep legacy sizing and schedules, organisations may end up funding unused capacity, duplicated environments, and forgotten resources that accumulate silently over time. That creates budget pressure, but it also reduces visibility into which services are truly essential.
Failure mechanism: Cost leakage usually arises from a combination of oversized instances, poor tagging, long-lived test and backup infrastructure, and weak ownership of shared accounts or subscriptions. Because the cloud makes provisioning easy, the same controls that restrained expansion on premises often disappear, and waste becomes persistent rather than temporary.
Impact: Leaders lose the savings case for migration, finance loses confidence in cloud forecasts, and engineering teams may be forced into blunt cost cuts that harm resilience or performance. In some organisations, unmanaged spend becomes a governance issue because no one can clearly explain which workload is driving the bill.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 4 — Secure Configuration of Enterprise Assets and Software | Controls cloud baseline waste and oversized deployments after migration. |
| CIS Control 8 — Audit Log Management | Supports spend attribution and visibility into who created or changed costly resources. | |
| Recommendation — Harden and rightsize migrated workloads, then remove unnecessary services and default capacity. Log provisioning and change activity so hidden resources and drift are easier to find. | ||
| NIST CSF 2.0 | ID.BE — Business Environment | Links migration cost outcomes to workload criticality, ownership, and operating assumptions. |
| GV.RM — Risk Management Strategy | Cost expectations need governance that compares migration spend with realised business value. | |
| Recommendation — Map each migrated workload to its business purpose, owner, and expected demand pattern. Set cost and optimisation checkpoints in the migration risk strategy before approving rehosting. | ||
Practitioner Guidance
What to prioritise: Separate migration success from cost success. A workload can be technically stable after rehosting and still be economically wrong for months if no one owns rightsizing, scheduling, or storage cleanup.
What to verify: Check whether the cloud baseline includes duplicated environments, legacy licensing, unused capacity, and hidden support costs. If those items are missing from the comparison, the savings story is probably overstated.
What good looks like: The workload has a measured baseline, clear cost owner, tagged spend, and a documented plan for the next optimisation step, whether that is rightsizing, commitment purchases, or selective modernisation.
Practitioner takeaway: Lift-and-shift should be treated as a relocation step, not an optimisation strategy, because cloud savings are usually earned through operating changes after the move, not delivered by the move itself.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
