How to Predict and Control Spend Before Migration

In this Insight

Most organisations begin thinking about cloud costs when bills arrive. High-performing organisations begin thinking about cloud economics when migration decisions are being made — because by the time the first invoice lands, the architectural choices, governance structures, and consumption patterns that determine what cloud actually costs are already in place.

A cloud cost assessment is a structured evaluation of an organisation's current IT economics, its projected cloud spend under different architectural scenarios, and its readiness to govern cloud spend effectively once migration begins. It is not primarily about reducing costs. It is about building the visibility, forecasting capability, and governance foundations that make cloud spend understandable, attributable, and controllable.

The FinOps Foundation treats cost visibility as the foundational capability from which all cost management flows. The World Bank's Economics of Cloud Infrastructure research identifies the structural factors — energy, connectivity, regulatory friction, skilled labour, and risk — that shape unit cloud costs in ways that differ materially across geographies. Microsoft's Cloud Adoption Framework integrates cost management into migration planning as a prerequisite, not an afterthought.

The consistent message across sources is the same: cloud cost assessment is not a financial exercise performed alongside migration planning. It is a readiness discipline that determines whether migration decisions are economically sound.

The Wrong Question

When organisations begin a cloud programme, the first financial question is almost always the same.

How much will cloud cost?

It is a reasonable question. It is also, in isolation, the wrong one. Not because cost does not matter — it matters considerably — but because it frames the problem in a way that leads to answers that are technically correct and practically misleading.

The answer to "how much will cloud cost?" is almost always a number derived from provider pricing calculators, applied to a workload inventory of uncertain accuracy, with assumptions about consumption patterns that have not been validated, and without accounting for the governance mechanisms that do not yet exist. The number looks credible. It rarely predicts reality.

The better question — the one that a cloud cost assessment is designed to answer — is different.

How well does our organisation understand the economics of what we have today, and the economics of what we are planning to build?

That question changes the scope of the conversation. It asks about visibility, not just spend. About governance, not just pricing. About forecasting accuracy, not just estimates. About unit economics, not just totals. About the organisational capability to manage cloud spend effectively — not just the capability to calculate it once before migration begins.

The difference between organisations that manage cloud spend well and those that do not is rarely the quality of their initial cost estimates. It is the maturity of the financial governance they build around their cloud environment — and whether they build it before migration or attempt to retrofit it afterwards.

The Cost Visibility Gap

There is a pattern in cloud cost management that appears with enough consistency to warrant a name.

An organisation migrates to cloud. Billing data becomes available. Someone — usually a finance team member or a cloud architect — pulls together a cost report. The report shows total monthly spend by service and by account. Everyone can see what cloud costs. And yet no one can explain why it costs what it does, whether the spend represents good value, which products or teams are driving consumption, or whether the trajectory is sustainable.

The bills are visible. The economics are not.

CloudFruition Named Pattern: The Cost Visibility Gap

The Cost Visibility Gap is the distance between having raw billing data and having actionable insight into cloud economics. An organisation in the Cost Visibility Gap can see its total cloud spend. It cannot see cost per product, per customer, per transaction, or per team. It cannot answer the questions that financial decisions depend on: Is this spend justified by the value it creates? Where is consumption growing and why? Which architectural choices are driving cost and which are not? Without closing this gap, optimisation efforts tend to reduce spend temporarily rather than improve economics durably.

The FinOps Foundation identifies cost visibility as the foundational capability of cloud financial management — the base from which allocation, forecasting, optimisation, and governance all flow. Organisations that lack meaningful cost visibility are not in a position to make well-informed financial decisions about cloud, regardless of how sophisticated their architecture is or how experienced their engineering team.

The cost assessment question is not whether the organisation can see its bills. It is whether the organisation has the visibility needed to make decisions.

What a Cloud Cost Assessment Actually Covers

A cloud cost assessment is a structured evaluation across five connected areas. They are not sequential steps so much as interdependent lenses — each one revealing something about the organisation's financial readiness that the others alone cannot show.

Cost baseline: Understanding what you spend today

Before modelling cloud costs, an organisation needs an accurate picture of what its current IT environment actually costs. This sounds straightforward. It rarely is.

On-premises IT costs are distributed across budget lines in ways that make the true total difficult to assemble: infrastructure hardware, software licensing, maintenance contracts, data centre facilities, power and cooling, staff time for operations and maintenance, and the overhead associated with running environments that cloud managed services would eliminate. Many organisations undercount the true cost of on-premises IT, which produces a cloud comparison that is selectively optimistic.

A cost baseline assembles the complete current-state picture. Not to prove that cloud is cheaper — sometimes it is not, and a credible assessment acknowledges that — but to ensure the comparison is honest.

Cost modelling: Projecting what cloud will cost under different scenarios

Cloud cost modelling requires assumptions about architecture patterns, workload sizing, consumption volumes, and operational design. The accuracy of the model depends on the quality of those assumptions — which is why cost modelling and workload inventory work need to happen together rather than sequentially.

The most common modelling errors are not arithmetic. They are architectural. Using headline unit pricing without workload context produces projections that diverge from reality as soon as actual consumption begins. Ignoring data egress and interconnect costs — the charges for moving data between cloud regions, between cloud and on-premises, and between cloud and the internet — produces models that look accurate for compute and storage and miss significant costs at scale. Failing to model the operational overhead of managing a cloud environment — monitoring, logging, security tooling, governance engineering — produces a cost picture that is systematically incomplete.

Google Cloud's architecture framework makes the connection explicit: cost optimisation is shaped by design choices. Architecture decisions about managed services versus self-managed, stateful versus stateless design, decoupled versus tightly integrated systems — these are cost decisions as much as they are technical decisions. A cost model built without architectural context is not a cost model. It is an estimate.

Cost allocation and unit economics — understanding what drives spend

Total cloud spend is a management metric. Unit economics are a decision metric.

The question that matters for most financial decisions is not "what did we spend on cloud this month?" but "what did it cost to serve a customer, process a transaction, run a workload, or support a product?" Unit economics — cost per transaction, per user, per API call, per dataset — connect cloud spend to business value in a way that totals cannot.

The FinOps Foundation's maturity model defines best-in-class cost allocation as more than 90% of cloud spend attributed to known owners, with commitment discount coverage above 80% and forecast variance below 5%. These are not aspirational targets. They are operational benchmarks that define what meaningful cost governance looks like in practice. At the Crawl stage — where many organisations begin — allocation covers around 70% of spend and forecast variance may be below 20%.

The gap between where an organisation is and where it needs to be is a readiness gap. A cost assessment makes it visible.

Forecasting and budgeting: Predicting what cloud will cost with confidence

Cloud cost forecasting is harder than on-premises budgeting for a structural reason: cloud costs are consumption-based and dynamic. They respond to architectural decisions, operational choices, workload behaviour, and organisational growth patterns in ways that fixed infrastructure costs do not.

Organisations that build forecasting capability before migration — by understanding workload consumption patterns, establishing baseline metrics, and designing governance mechanisms that create predictable spend behaviour — produce forecasts that remain accurate. Organisations that begin forecasting after migration, reactively, from actual spend data, tend to produce forecasts that lag behind reality and provide limited decision support.

Cost governance: Designing the structures that keep spend accountable

Cost governance is the set of mechanisms that make cloud spend visible, attributable, and controllable over time. It covers tagging taxonomies for cost attribution, account and subscription structures that reflect business boundaries, alerting and anomaly detection for spend patterns, defined decision rights for commitment purchases and architectural choices with cost implications, and the processes for reviewing and acting on cost data.

Microsoft's Cloud Adoption Framework separates Govern as a major adoption domain because governance does not emerge naturally from cloud adoption. It requires deliberate design. Cost governance designed before migration — as part of the landing zone and operating model — is consistently more effective and less expensive than governance imposed on an environment that has grown without it.

CloudFruition Insight: The organisations that manage cloud costs most effectively are not those that negotiate the best discounts. They are those that build the visibility, allocation, and governance structures that make spend understandable before it becomes unmanageable.

Cost Governance Debt

Governance Debt — the concept introduced in the Cloud Assessments pillar — has a specific financial dimension that is worth naming separately.

CloudFruition Named Pattern: Cost Governance Debt

Cost Governance Debt accumulates when cloud environments grow without the cost governance structures needed to manage them. Tagging policies are not enforced from day one, so cost attribution becomes retrospective and incomplete. Account structures do not reflect business boundaries, so spend cannot be meaningfully allocated. Commitment purchases are made without understanding workload patterns, creating stranded reservations. Anomaly alerting is not configured, so cost spikes are discovered in monthly invoices rather than in real time. Each of these individually is a manageable problem. Together, they create a governance backlog that limits the organisation's ability to optimise, forecast, or make informed architectural decisions — and that grows more expensive to remediate with each migration wave that adds workloads to an ungoverned environment.

The FinOps Foundation's maturity model and associated practice guidance emphasise that early governance decisions — tagging strategy, ownership models, budget thresholds, commitment policies — are significantly easier to implement before the environment is populated than after. The debt metaphor is accurate: shortcuts taken early compound, and the interest accumulates in the form of wasted spend, failed forecasts, and audit findings.

The cost assessment question is not whether perfect governance can be achieved before migration begins. It is whether the foundational governance structures — the ones that determine whether spend can be seen, attributed, and acted upon — are in place before the environment grows beyond the point where they can be imposed without disruption.

Reactive Cost Management

Related to Cost Governance Debt, but distinct from it, is the pattern of how organisations respond to cost information.

Many organisations do not think carefully about cloud cost governance until a bill arrives that is larger than expected. The response is typically a cost optimisation sprint: a focused effort to identify and eliminate waste, right-size instances, review commitments, and implement the governance mechanisms that should have been in place from the start. Costs reduce. The underlying governance remains incomplete. The cycle repeats.

CloudFruition Named Pattern: Reactive Cost Management

Reactive Cost Management is the pattern of responding to cloud cost surprises rather than designing the governance structures that prevent them. It is characterised by cost action triggered by negative events — an unexpected invoice, a budget overage, a CFO inquiry — rather than by continuous, governed visibility into spend patterns. Reactive Cost Management produces temporary cost reductions without durable governance. Each optimisation sprint addresses the symptoms of the most recent surprise without building the capability to prevent the next one.

The FinOps Foundation and practitioner commentary consistently identify reactive cost management as a common barrier to mature cost governance. The intentional alternative is not more aggressive cost optimisation. It is building the cost governance capability — visibility, allocation, forecasting, and decision rights — that makes reactive responses unnecessary.

A cloud cost assessment is the structured process of evaluating whether the organisation has that capability, or has a plan to build it before migration scales.

The CloudFruition Cost Readiness Model

If visibility, allocation, forecasting, governance, and optimisation are the dimensions of cloud cost readiness, how should an organisation evaluate its maturity across them? The following model draws on FinOps Foundation maturity indicators to provide a practical readiness lens.

Crawl: Foundational awareness

At this stage, the organisation has basic billing visibility — raw spend data by service and account — but limited attribution to business dimensions. Cost allocation covers around 70% of spend. Commitment discount coverage is around 60%. Forecast variance may be below 20%. Governance policies exist but are not consistently followed. Cost action is largely reactive.

The readiness implication: an organisation at Crawl maturity is not ready to make confident financial decisions about a large-scale migration. It can estimate. It cannot forecast with confidence or govern spend effectively at scale.

Walk: Operational governance

At this stage, the organisation has meaningful cost allocation — around 85% of spend attributed to known owners — with commitment coverage above 75% and forecast variance below 10%. Automation handles most routine governance requirements. Unit economics are beginning to be tracked. Cost decisions are informed rather than reactive for most workloads.

The readiness implication: an organisation at Walk maturity can proceed with migration at scale and manage spend effectively, provided the governance structures established are maintained and extended as the environment grows.

Run: Financial confidence

At this stage, more than 90% of spend is allocated to known owners, commitment coverage exceeds 80%, and forecast variance is below 5%. Cost governance is embedded in operating model rather than managed as a separate function. Unit economics are tracked and connected to business decisions. Difficult edge cases — shared services cost allocation, AI workload economics, multi-cloud attribution — are addressed rather than avoided.

The readiness implication: an organisation at Run maturity has the financial visibility and governance capability to make confident economic decisions about cloud, including complex decisions about AI workloads, sovereignty-constrained architectures, and multi-cloud cost trade-offs.

The purpose of a cost assessment is not to certify which stage an organisation is at. It is to understand the gap between current capability and what the planned programme requires — and to produce a specific, time-bound plan for closing it.

Architecture Is a Cost Decision

One of the most important shifts in cloud cost thinking is the recognition that cost management is not primarily a financial management activity. It is an architecture discipline.

The choices made during migration planning — managed services versus self-managed, single-region versus multi-region, stateful versus stateless design, tightly coupled versus decoupled architecture — determine cloud economics more than any discount negotiation or optimisation sprint that follows. Google Cloud's architecture framework makes this explicit, treating cost optimisation as a primary architecture pillar alongside reliability, security, and performance.

This matters for cost assessment because it means that cost assessment and architecture assessment need to happen together. A cost model built on an architectural assumption that changes during migration design will diverge from reality. An architectural decision made without understanding its cost implications may be technically sound and economically unsound.

The cost assessment question is not just "what will this cost?" It is "what architectural choices are available to us, what do those choices cost under different scenarios, and which choices best balance cost against the performance, resilience, and governance outcomes we need?"

That is a richer conversation than pricing calculator outputs can support. It requires the kind of structured analysis that a cost assessment is designed to produce.

CloudFruition Insight: Architecture decisions made during migration planning are cost decisions. The organisations that understand this — and bring cost analysis into architecture discussions from the start — consistently produce cloud environments that are both technically sound and economically sustainable.

Sovereignty and the Cost of Compliance

For organisations with data residency requirements, regulatory constraints, or sovereignty obligations, cloud cost assessment has an additional dimension that standard enterprise frameworks do not fully capture.

The World Bank's Economics of Cloud Infrastructure research identifies a multi-factor unit cost model for cloud infrastructure that includes energy costs, capital costs, connectivity costs, skilled labour costs, and regulatory compliance costs and risk premia. The research shows that structural factors — particularly location, energy infrastructure, connectivity, and regulatory friction — can materially change unit infrastructure costs in ways that standard provider pricing does not reflect.

For organisations operating in emerging markets or under sovereignty constraints, this has direct implications for cost assessment. Deploying in specific regions to meet residency requirements, using private connectivity to comply with jurisdictional controls, maintaining hybrid architectures to keep regulated data on-premises, or using sovereign cloud offerings that carry premium pricing relative to standard hyperscaler regions — all of these have cost implications that need to be built into the assessment rather than discovered after architectural decisions are locked in.

The sovereignty cost question is not simply "is sovereign cloud more expensive?" It is "what is the full cost of compliance with our regulatory obligations, and how does that cost compare across available architectural options?" That question cannot be answered by a standard pricing model. It requires a cost assessment that takes sovereignty seriously as an input rather than treating it as a constraint to be minimised.

For public sector organisations and those operating across African and emerging markets, the World Bank's research provides the most substantive available evidence on how location, connectivity, regulatory friction, and institutional factors shape cloud economics in contexts where standard hyperscaler region assumptions do not apply. A cost assessment in these contexts should draw on that evidence explicitly, rather than applying cost models designed for markets where the structural assumptions are different.

Cloud Cost Readiness and AI

The connection between cloud cost assessment and AI readiness is direct, and it is becoming more consequential as AI programmes move from experiment to enterprise scale.

AI workloads — training, inference, data processing, and model serving — produce consumption patterns that are materially different from standard application workloads. They can be significantly more expensive, their cost profiles are often less predictable, and the governance mechanisms needed to manage them effectively are more demanding than those needed for conventional cloud workloads.

Google Cloud's architecture guidance and McKinsey's risk management research both identify cost visibility, allocation, and governance as prerequisites for scalable AI programmes. An organisation that lacks mature cost governance for its existing cloud environment is not well-positioned to manage the economics of AI workloads — which tend to amplify both the benefits of good governance and the consequences of poor governance.

The cost assessment implication is practical: organisations planning AI programmes should assess their cloud cost readiness as part of their AI readiness work, not separately from it. The questions are the same. Can spend be attributed to specific workloads and business outcomes? Can consumption be forecast with sufficient confidence to budget AI programmes reliably? Are the governance mechanisms in place to prevent AI pilots from becoming ungoverned cost centres?

Without clear answers to those questions, AI ambition tends to outpace financial governance — and the gap becomes visible in the form of AI cost surprises that are considerably larger than the cloud cost surprises that preceded them.

CloudFruition Insight: AI workloads amplify cloud economics in both directions. Organisations with mature cost visibility and governance tend to find AI workloads manageable. Organisations without it tend to find AI costs the most visible and uncomfortable consequence of the governance they deferred during cloud migration.

What a Cost Assessment Produces

A well-conducted cloud cost assessment produces five connected outputs that together give the organisation the financial evidence base it needs to make confident migration decisions.

A current-state cost baseline — the honest, complete picture of what the current IT environment costs, including the costs that are not in a single budget line and the costs that are often excluded from on-premises versus cloud comparisons.

Scenario cost models — projected cloud spend under two or three architectural scenarios, with assumptions made explicit and sensitivity analysis showing how costs change if key assumptions change. The value of scenarios is not that they predict the future accurately. It is that they make the cost implications of architectural choices visible before those choices are made.

A FinOps maturity assessment — an evaluation of where the organisation sits on the cost readiness spectrum across visibility, allocation, forecasting, governance, and optimisation, with a specific gap analysis showing what needs to be in place before migration scales.

A cost governance design — the tagging taxonomy, account structure, alerting thresholds, commitment strategy, and decision rights framework that will govern cloud spend from the first day workloads migrate. Designed before migration, not retrofitted afterwards.

A financial roadmap — a time-bounded plan for closing the gap between current cost readiness and the maturity the planned programme requires, with owners and milestones connected to migration wave sequencing.

These outputs connect directly to the migration planning, landing zone design, and operating model work that follows. Cost assessment is not a separate financial track. It is the financial dimension of readiness — and its outputs belong in the same conversation as the technical and governance readiness work.

What the Assessment Reveals About Organisational Readiness

There is a broader observation that emerges from cloud cost assessment work, one that sits alongside the financial findings and is often more useful to leadership.

The quality of an organisation's cost governance is a reliable indicator of the quality of its cloud governance overall. Organisations that have invested in cost visibility, allocation, and forecasting tend to have also invested in operating model clarity, decision rights, and accountability structures. The disciplines reinforce each other.

Conversely, organisations with significant Cost Governance Debt tend to have corresponding governance gaps in security posture, operating model, and skills. The cost governance picture is a diagnostic window into the organisation's overall cloud maturity.

This is not a coincidence. It reflects a consistent principle: the organisations that govern cloud spend well are the organisations that have decided, deliberately, to understand what they are doing rather than simply doing it. That decision — to invest in understanding before committing to scale — is the same decision that separates cloud programmes that deliver durable value from those that deliver a technically successful migration and a financial surprise.