The three costs most cloud business cases forget

Lift-and-shift produces the most flattering migration model and the most expensive first invoice. The gap is rarely a surprise to the finance team; it is a surprise to everyone who built the model.

Three line items account for most of it.

1. Egress, and the architecture that causes it

Egress is charged when data leaves a region, a provider, or both. It is rarely the dominant cost at small scale, which is precisely why it gets modelled as zero.

What actually generates it is architectural. A system that replicates a database across three availability zones to meet availability targets generates continuous replication traffic forever. A nightly full backup to another region generates a predictable monthly sum. An analytics pipeline reading raw transaction tables across a network boundary generates egress proportional to growth.

The pattern to watch: every resilience or disaster-recovery requirement has a recurring data-transfer cost attached to it, and those requirements are usually non-negotiable and rarely costed.

You cannot avoid egress entirely. You can make it visible before you commit, by modelling the actual replication and backup topology rather than an average data size.

2. The engineering time to operate it

The migration project is budgeted. The eighteen months afterwards usually are not.

Cloud platforms shift work from provisioning to operating. Someone has to own identity and access. Someone has to own cost monitoring and rightsizing. Someone has to own the deployment pipeline and keep it working. Someone has to be on call.

In an on-premise estate these often sat with a small infrastructure team. In cloud they scale with the estate rather than the workload, and they are the reason many migrations are followed by an unplanned second engagement.

Model it honestly: two to three full-time equivalents for a mid-sized estate, growing with environments, not services. If the business case cannot absorb that, the migration will either be understaffed or quietly abandoned, and both outcomes are expensive.

3. Deferred remediation

The migration carries the old estate's inefficiency with it. The database still has an index nobody uses. The instance class still reflects 2019 capacity planning. The licence costs were never right and are now a per-hour charge.

Migration preserves behaviour, so it preserves waste. A three-year projection that simply carries over current consumption will show cloud as more expensive, and it will be correct.

Model a remediation phase in scope from the start:

• rightsizing based on observed utilisation, not vendor defaults
• identifying licences that no longer apply in the new estate
• storage tiering for data with a genuine access pattern
• shutting down the things the old estate kept running "just in case"

The remediation phase is where most of the savings become real. A migration plan that omits it is a cost transfer, not a saving.

A workable three-year structure

Separate the projection into three phases with different assumptions:

Phase one — baseline. Current estate costed as-is, plus migration project cost, plus the first year of cloud consumption at current utilisation. This is usually the phase that gets approved.

Phase two — stabilisation. Same consumption, plus operations headcount at the modelled ratio. Add egress for the replication and backup topology you actually designed.

Phase three — optimised. Consumption reduced by rightsizing, storage tiering, commitment discounts applied against a real usage curve, and decommissioned legacy systems removed.

Publishing all three, with the assumptions stated, is what lets a finance team interrogate the model rather than argue with a single number.

What to demand from whoever builds the model

• Utilisation figures from the existing estate, measured rather than estimated
• An explicit egress topology, not an average data size
• An operations ratio, agreed as an assumption rather than discovered later
• A remediation phase with named savings and a schedule

A model that omits these is not optimistic by accident. It was built to produce an answer the sponsor wanted.