Cloud migration cost: where the overrun comes from

Cloud migration cost is usually discussed twice: once in a business case built on list prices and a sizing spreadsheet, and again three months after the first wave, when the invoice settles well above it. The gap comes from the run rate, from effects that are individually small, predictable and invisible until the estate is populated. This article covers where they come from and what controls them.

The cloud migration cost overrun shows up in the run rate

A migration has two cost curves. The project curve is bounded, visible and attended to, since it has a budget holder and a monthly report. The run curve begins with the first migrated workload and continues indefinitely, and it is the one that decides whether the business case was right.

This explains the timing of the surprise. At go-live, the invoice is small because little has moved. Three months later, several waves have landed, the source environment is still running, the dev and test estate has been rebuilt in the target, and the run curve is well above the modelled figure. Nothing went wrong in a way anyone can point to.

The design-time decisions that shape this curve, the disposition per system, the sequencing and the run model, are covered in our article on cloud migration strategy. What follows is the other half: the mechanics that generate the invoice once workloads are running, and the controls that keep them visible.

Double-run cost: paying for both environments

For as long as a wave is in flight, two environments exist. The source cannot be switched off at cutover, because the rollback window has to stay open and reconciliation has to be repeated on live data. A hyper-care period of two to four weeks is normal, and decommissioning is a separate scheduled decision after it.

Business cases routinely model this period as a few weeks of overlap. In practice it stretches, for reasons that are all individually reasonable: a wave slips past a period close, a dependent system is not ready, a licence runs to a renewal date, a partner interface needs longer notice. Each extension is defensible and each one adds a month of paying twice.

Two items are usually missing from the model. Decommissioning work itself has a cost, in engineering time, in data archival for retention obligations, and occasionally in contract exit fees. A system is not free to switch off.

And on-premise cost does not fall linearly as workloads leave. Hardware is already bought, support contracts run to their term, floor space and power are committed, and the shared platforms underneath, the storage array, the backup system, the network, stay in place until the last dependent workload is gone. Savings arrive in steps when a whole platform can be retired, and the steps come later than a linear model suggests.

The practical control is to model the transition explicitly, with a per-wave decommissioning date, an owner, and the specific contract or platform that can be released on that date. A transition modelled as a percentage is a transition nobody is accountable for shortening.

Oversizing: the largest cloud migration cost driver

In DNA Solutions engagements, this is the largest single contributor, and it is a habit rather than a decision.

On-premise capacity is bought in advance, for the peak expected over the life of the asset, with headroom for growth and for the fact that adding capacity later takes a quarter. That is sound procurement under those constraints. The resulting servers run at low average utilisation, which costs nothing extra once purchased.

A lift-and-shift migration that maps each server to an equivalent instance carries that headroom into a model where it is billed monthly. Capacity provisioned for a peak that occurs twice a year is paid for twelve months a year, and the one-off over-provisioning decision becomes a recurring charge.

The correction is rightsizing against observed load rather than against the previous specification, which requires a performance baseline taken before the move and monitoring in place after it. It is deliberately done after stabilisation: rightsizing during hyper-care removes headroom at the moment the estate is least understood, and a performance incident attributed to the migration costs more than the saving.

Where a system genuinely has a sharp, predictable peak, the target architecture should scale for it rather than provision for it permanently. That is a design change, so it belongs to the disposition decision rather than to a later cost exercise, which is one reason a rehost-everything approach defers expensive work into the run phase.

Cloud migration cost attribution and the tagging standard

A cloud bill is a long list of line items with no owner attached. Without attribution, the cost conversation happens between finance and a central infrastructure team, neither of which controls the decisions that generate the charges.

Attribution requires a tagging standard enforced at provisioning time, through policy that refuses untagged resources. The distinction matters: a tagging standard published as a guideline produces partial coverage, and partial coverage is close to useless, because the untagged remainder is where the unexplained growth accumulates. Tagging applied retroactively across a populated estate is work nobody schedules.

The minimum tag set is small: owning team, application or service, environment, and cost centre. What makes it work is that the resulting report goes to the team that can change the number, on a cadence short enough to connect a change to its cause. A quarterly cost review reaches people who no longer remember what they deployed in week two.

Two further items belong in the same discipline. Untagged and orphaned resources need a standing sweep: volumes detached from deleted instances, unattached addresses, snapshots retained by a policy nobody reviewed, load balancers in front of nothing. These accumulate quietly and are cheap individually. And anomaly alerting on the daily spend curve catches the misconfiguration that would otherwise be discovered on the monthly invoice, three weeks after it started.

Idle non-production environments and scheduled shutdown

Development, test, staging, training, integration and pre-production environments frequently outnumber production instances. On-premise they ran continuously because there was no reason to stop them.

In a metered model, a non-production environment running outside working hours is charged for time in which nobody used it. A five-day, ten-hour usage pattern is under a third of the week. Scheduled shutdown of non-production compute is the highest-return, lowest-risk cost control available in most estates, and it is postponed because it needs a small amount of engineering and a conversation with the teams affected.

Two related items belong here. Environment sprawl: environments created for a project that ended, kept because deleting them requires a decision. An expiry date at creation, with renewal by request, converts the default from keep to release. And data volume in non-production: full production copies refreshed nightly into four environments multiply storage and often carry personal data into places with weaker controls. A subset is usually sufficient for the purpose.

Storage tiers and lifecycle policy for cold data

Storage lands on the tier chosen at migration time and stays there. Access patterns are heavily skewed: a minority of data is read regularly, and the remainder is retained because retention policy or habit requires it. Paying the highest tier for data last read three years ago is a standing charge with no corresponding use.

Lifecycle policies that move objects to cooler tiers on an access-based rule address this, and they need one input the migration usually has not produced: an actual retention position per dataset, meaning how long the organisation is obliged to keep each thing. Without that, nobody will authorise deletion or archival, and the default is to keep everything on the tier it arrived on.

Backup and snapshot retention deserves specific attention, since it is set once from a template and compounds. Daily snapshots retained for a year, across a populated estate, is a large number that nobody chose.

Data egress charges in a split estate

Data transfer out of the target infrastructure is charged, and it is the line item that most often appears unexpectedly, because it is generated by traffic patterns rather than by provisioned resources.

The situation that produces it is a split estate: a dataset in the target and a system that reads it still on-premise, or two applications that share data placed in different waves. Every query then crosses the boundary, and the charge continues for as long as the split does. This is the concrete cost of sequencing systems by org chart rather than by data dependency, and it is why waves are formed from the dependency graph.

Two other sources are worth checking. Cross-zone and cross-region traffic inside the target, generated by an architecture spread for resilience without attention to the data path. And third-party integrations pulling large extracts on a schedule, often a partner report that was free when both ends sat in the same data centre.

Reserved instances and committed spend bought too early

Reserved capacity and committed-spend discounts are substantial and they require knowing the shape of the estate for one to three years. Bought too early, they lock in the pre-rightsizing footprint, which is the footprint you intend to reduce, and the discount is then an argument against reducing it.

The workable sequence is: migrate, stabilise, rightsize against observed load, then commit to the resulting baseline, keeping a variable margin for the part of the load that is genuinely uncertain. Commitments are also worth staggering rather than aligning to a single renewal date, so that the whole estate is not renegotiated in one quarter.

Pressure to commit early usually comes from a business case that needs the discount to work. A business case that only works with a commitment bought before the estate is understood is a business case with a sequencing problem in it.

Measuring cloud migration cost per business transaction

Total cloud spend rises as the estate grows and as the business grows, so a programme judged on total spend cannot distinguish growth from waste. The figure that survives is unit cost: cost per business transaction, per invoice processed, per active user, per vehicle, whichever unit the organisation already uses.

Unit cost has two useful properties. It can improve while total spend increases, which is the normal state of a growing platform and is otherwise reported as a failure. And it is comparable over time, which makes an optimisation effort measurable.

That figure needs an owner with the authority to act on it. Where the run responsibility sits with a team that did not choose the architecture and cannot change it, the number is reported and nothing follows. This is the operating model question, and answering it after the migration is how organisations end up creating a cost-recovery function to undo decisions made eighteen months earlier.

Talk through your cloud migration costs

DNA Solutions works on this as part of our cloud practice, usually pairing the rightsizing and tagging work with the wave plan so that attribution exists before the estate is populated rather than after. Where the run model and the ownership question have to be settled across several teams first, that sits under IT consulting, and it is worth doing before the first wave rather than after the third invoice. Talk to us.