Avoiding Costly Mistakes

In this Insight

Most cloud migration programmes fail not because the technology did not work, but because the risks that actually mattered were not the ones being managed.

Application compatibility, infrastructure dependencies, cutover planning — these receive careful attention. Governance immaturity, operating model gaps, security weaknesses discovered after workloads have moved, regulatory constraints that reshape architecture mid-programme, sovereignty requirements that were never mapped — these tend to surface later, at greater cost, and with less time to address them well.

A cloud migration risk assessment is a structured process for identifying, prioritising, and mitigating the risks that influence migration outcomes across all their dimensions: technical, operational, governance, financial, security, compliance, sovereignty, and increasingly AI-related. Leading frameworks from AWS, Google Cloud, Microsoft, and institutional sources including the World Bank treat migration risk as a continuous, cross-functional governance discipline — not a pre-migration checklist.

This article explains what migration risk assessment covers, why the most consequential risks are often the least visible ones, and how organisations can approach risk assessment in a way that builds migration confidence rather than migration anxiety.

The Risks That Actually Cause Problems

There is a consistent pattern in cloud migration programmes that fail to deliver their expected outcomes, or that succeed technically while underperforming commercially.

The technical migration worked. Workloads moved. The infrastructure is running. But the programme is slower than planned, more expensive than projected, or producing less value than the business case promised. In retrospect, the problems trace back to decisions made — or not made — before the first workload moved.

Governance structures were assumed rather than designed. Security controls were deferred to a post-migration hardening phase that never fully materialised. The operating model for running cloud workloads was not ready when the workloads arrived. Regulatory requirements were identified too late to inform architecture decisions. Sovereignty constraints reshaped landing zone design mid-programme. And somewhere, quietly, AI ambitions accelerated the migration timeline before the foundations were ready to support them.

Deloitte's cloud migration research identifies a consistent set of overlooked ingredients in migration programmes: people, governance structures, cross-functional collaboration, and cybersecurity from the start. These are not specialist concerns for edge cases. They are the dimensions that most commonly determine whether a technically sound migration delivers organisational value.

CloudFruition Insight: The risks that cause the most damage in cloud migration programmes are rarely the ones that receive the most attention during risk assessment. Technical execution risks are well-documented and actively managed. Governance, operating model, and sovereignty risks tend to be underweighted until they become problems.

The purpose of a migration risk assessment is to change that balance — to surface the full range of risks before they are expensive to address, and to produce a prioritised, governed plan for managing them throughout the programme.

Migration Feasibility Is Not Migration Readiness

Before exploring what a migration risk assessment covers, it is worth addressing a distinction that the Content Strategy Brief names directly and that the Intelligence Pack research confirms.

A workload can be technically feasible to migrate — compatible with cloud infrastructure, capable of being rehosted or replatformed — while still carrying governance, regulatory, operational, or sovereignty risks that make migration unwise or premature.

CloudFruition Named Pattern: Migration Feasibility vs Migration Readiness

Migration feasibility asks: can this workload move to cloud? Migration readiness asks: should this workload move to cloud now, given the organisation's current governance maturity, operating model, compliance posture, and risk tolerance? A technically feasible migration that proceeds before readiness is established creates migration risk rather than managing it. The risks that form in the gap between feasibility and readiness tend to compound across subsequent migration waves.

Google Cloud's migration guidance identifies regulatory constraints and data localisation as wave-planning factors — dimensions that can determine not just how a workload migrates, but whether it should be included in an early wave at all. AWS treats the Migration Readiness Assessment as the mechanism for establishing whether the organisation is ready to migrate at scale without pausing mid-way to fix foundational gaps.

The distinction between feasibility and readiness is the conceptual foundation of migration risk assessment. It reframes the risk question from "can we do this?" to "are we prepared to do this well?"

The Eight Dimensions of Migration Risk

Migration risk is multi-dimensional. Leading frameworks from AWS, Microsoft, and Google Cloud — alongside institutional guidance from the World Bank and Deloitte — consistently identify the same broad categories. Understanding them clearly is the first step toward assessing them well.

Technical risk is the dimension most organisations assess most thoroughly: application incompatibility, dependency complexity, poor inventory quality, data migration failure, network design issues, weak rollback capability, and landing zone immaturity. These are real risks and they deserve the attention they receive. They are also, in isolation, an incomplete picture of migration risk.

Operational risk covers the gap between what the technology can do and what the organisation is prepared to do with it. Inadequate change management, weak incident response, poor runbook readiness, skills shortages, and failure to adapt operating models for cloud environments — these create operational fragility that technical migration success does not address. Microsoft's Cloud Adoption Framework positions operational management as a major adoption domain for this reason: cloud does not manage itself, and the operational model needed to run it well is different from the one that ran on-premises infrastructure.

Governance risk arises when the policies, decision rights, and accountability structures needed to manage a cloud environment are absent or immature. Undefined ownership of cloud decisions, missing tagging and cost allocation standards, delayed control implementation, and poor cross-team coordination are all governance risks — and they compound with each migration wave that adds workloads to an ungoverned environment. Microsoft's CAF governance compliance guidance treats governance rules as active risk mitigants, not administrative overhead.

Financial risk in migration encompasses more than cost overruns. Sequencing errors that create unnecessary dual-running costs, overspending driven by poor governance visibility, stranded commitment purchases, and inadequate forecasting tied to migration wave timing are all financial risks that a cost assessment alone does not fully address. Financial risk and governance risk are closely connected: ungoverned environments produce unpredictable costs.

Security risk in cloud migration is distinct from the security risk of running a static on-premises environment. Misconfiguration — particularly of identity and access controls — is among the most common cloud security failure modes. Shadow IT that migrates outside the governed programme, weak monitoring during the transition period, exposed data paths created by incomplete network segmentation, and gaps in applying the shared-responsibility model correctly are all security risks that are most effectively addressed before workloads move rather than after incidents occur.

Compliance risk arises when legal and regulatory requirements are not mapped to workload placement, logging, retention, privacy controls, and audit capabilities before migration begins. For organisations in financial services, healthcare, public sector, and any context with sector-specific regulatory obligations, compliance risk can determine which architectural choices are available — not just which governance model is preferred.

Sovereignty risk has become a first-order migration consideration for a growing number of organisations. Data localisation requirements, jurisdictional exposure, region restrictions, sovereign cloud requirements, and legal uncertainty across borders can reshape landing zone design, region selection, vendor choices, and wave sequencing. Google Cloud's Trust Center and migration guidance both treat sovereignty, privacy, and compliance as migration design inputs rather than migration constraints. For public sector organisations and those operating in emerging markets, sovereignty risk often determines migration architecture more than technical preferences.

AI-related migration risk is the newest dimension, and it is becoming more consequential as AI programmes move from experiment to enterprise adoption. The OECD notes that demand for AI-ready data centre capacity could triple by 2030 — indicating the scale of pressure that AI ambition is creating on cloud migration decisions. Organisations may accelerate cloud migration specifically to support AI workloads, before the data governance, infrastructure controls, model governance, and risk ownership structures are mature enough to support them safely. A migration that creates an AI-capable platform before it is AI-governable creates a specific category of risk that is distinct from — and potentially more consequential than — standard migration risks.

The Migration Confidence Gap

One of the most consistent patterns in migration governance is worth naming precisely.

CloudFruition Named Pattern: The Migration Confidence Gap

The Migration Confidence Gap is the distance between perceived migration preparedness and actual cross-functional risk maturity. It forms when migration plans exist and technical readiness has been assessed, but governance, operating model, security, and compliance dimensions have not been evaluated with the same rigour. Leadership believes the programme is ready because the migration plan looks credible. The foundational risks that will shape programme outcomes are still unresolved. The gap is not visible until the programme is in execution — at which point the cost of closing it is considerably higher than it would have been during assessment.

AWS's migration readiness research identifies this pattern implicitly: the purpose of a readiness assessment is to identify strengths and weaknesses before migration at scale, not to validate a plan that has already been committed. Google Cloud describes migration risk assessment as a continuous data collection and mitigation workstream within programme governance — not a one-time pre-migration evaluation.

The Migration Confidence Gap closes when organisations treat risk assessment as a continuous discipline rather than a pre-migration checkpoint.

Risk Blindness

Related to the Migration Confidence Gap but distinct from it, there is a more specific cognitive pattern that affects how migration teams assess risk.

CloudFruition Named Pattern: Risk Blindness

Risk Blindness occurs when migration teams assess the risks they are trained to see — application compatibility, infrastructure dependencies, cutover complexity — while systematically underweighting the risks they are less equipped to evaluate: governance gaps, sovereignty constraints, operating model change requirements, and the downstream effects of AI ambitions on migration architecture. The risk register looks complete because it covers what the team knows. It is incomplete because it omits what the team does not know to look for.

Deloitte's research reinforces this directly: the overlooked ingredients in migration are not technical. They are people, governance, collaboration, and security — dimensions that require cross-functional assessment to surface, not just technical evaluation.

The practical implication is that migration risk assessment needs to involve stakeholders beyond the technical team. Microsoft's CAF is explicit about this: risk management spans strategy, planning, readiness, governance, security, and operational management. AWS prescriptive guidance specifies that readiness assessment requires input from business unit heads, finance, security, operations, and application owners. Risk Blindness forms when those voices are absent from the assessment.

How a Migration Risk Assessment Works

The process of migration risk assessment, as described across Google Cloud's migration guidance, AWS prescriptive guidance, and Microsoft's CAF, follows a consistent logic even when the specific frameworks differ.

Establish risk categories before assessing workloads. The eight dimensions above — technical, operational, governance, financial, security, compliance, sovereignty, and AI-related — provide the structure for a complete risk inventory. Beginning with a comprehensive taxonomy prevents Risk Blindness by ensuring the assessment covers dimensions that might not surface through workload-level analysis alone.

Assess risk at the programme level and the workload level. Some risks are programme-level: governance maturity, operating model readiness, security architecture, and sovereignty compliance affect the entire migration regardless of which workloads are in scope. Other risks are workload-specific: application complexity, dependency relationships, data classification, and compliance obligations vary by workload. Both levels need to be assessed, and they inform each other.

Classify risks by likelihood, impact, and control maturity. A risk register is not a list. It is a prioritisation tool. Each risk should be assessed on likelihood of occurrence, impact if it occurs, and the current maturity of the controls that mitigate it. Google Cloud recommends using risk heat maps — likelihood versus impact — as a structured format for making relative risk severity visible and comparable across dimensions.

Adjust migration wave sequencing based on risk findings. Google Cloud's migration guidance describes migration risk assessment as continuously refining foundational architecture and wave planning. Workloads with unresolved sovereignty constraints, immature compliance controls, or dependency risks that are not yet understood should not be in early waves regardless of their technical migration complexity. Wave sequencing is a risk management decision, not just a technical scheduling one.

Treat risk assessment as a continuous workstream, not a one-time gate. Google Cloud is explicit: migration risk requires a dedicated assessment workstream within programme governance, with continuous data collection and mitigation as the programme evolves. Risk posture changes across migration waves. New dependencies surface. Regulatory requirements are clarified. Operating model gaps become visible through early waves. A risk assessment conducted once at the start of a programme and never revisited is not risk management — it is a historical document.

Migration Risk Debt

There is a compounding dynamic in migration risk that mirrors the Governance Debt and Readiness Debt patterns described in earlier articles in this cluster.

CloudFruition Named Pattern: Migration Risk Debt

Migration Risk Debt accumulates when shortcuts taken to meet timeline targets leave unresolved control gaps, documentation deficiencies, and architectural risks that carry forward into subsequent migration waves. Each wave that migrates without fully resolving the risks identified in earlier waves adds to the debt. Security controls implemented partially. Compliance documentation incomplete. Rollback procedures untested. Operating model gaps acknowledged but not addressed. The debt is manageable in small quantities. As it compounds across waves, it creates a programme where later migration decisions are constrained by the unresolved risks of earlier ones — and where remediation becomes increasingly disruptive as the environment grows.

The practical implication is sequencing discipline. High-performing migration programmes, as described in the Intelligence Pack's risk maturity indicators, establish strong landing zone and governance foundations before moving sensitive or complex workloads. They build and validate rollback and incident response patterns through early waves before relying on them at scale. They treat each wave as an opportunity to improve risk maturity, not just to move more workloads.

Sovereignty Risk: A Closer Look

For many organisations, sovereignty risk deserves more attention than it typically receives in migration planning — not because it is more important than security or governance risk, but because its effects are architectural and consequential in ways that surface late if they are not assessed early.

Sovereignty risk in cloud migration encompasses data localisation requirements that restrict where specific data can be processed or stored, jurisdictional exposure from operating in cloud regions governed by foreign law, region restrictions that limit which cloud infrastructure is permissible for specific workload types, sovereign cloud requirements that mandate specific provider arrangements for regulated data, and the legal uncertainty that arises when operating across borders with different and sometimes conflicting regulatory frameworks.

Google Cloud's Trust Center and migration guidance both treat sovereignty as a design input — a factor that shapes landing zone architecture, region selection, network design, and wave sequencing from the start of programme planning. For public sector organisations, the World Bank's policy research shows that regulatory uncertainty and the concentration of cloud infrastructure in a small number of jurisdictions can create sovereignty risks that are material to migration strategy — not just compliance footnotes.

CloudFruition Named Decision: The Sovereignty-Before-Architecture Decision

The Sovereignty-Before-Architecture Decision is the choice to map sovereignty requirements — data residency, jurisdictional controls, regulatory permissibility, and vendor concentration risk — before finalising migration architecture decisions. Organisations that make this decision early design architectures that accommodate sovereignty requirements from the start. Organisations that make sovereignty assessments after architecture decisions are committed face the more expensive challenge of redesigning compliant architectures under programme pressure.

For organisations operating across African markets and other emerging market contexts, the World Bank's research identifies regulatory uncertainty and policy risk as specific migration concerns — noting that over-reliance on public investment and unclear cloud policy can deter private cloud infrastructure investment, increasing concentration and ecosystem risk. In these contexts, sovereignty risk assessment needs to account for a regulatory environment that may be developing alongside the migration programme rather than being fully established before it begins.

Cloud Migration Risk and AI

The connection between migration risk and AI deserves specific attention, because it is changing the risk landscape in a direction that many organisations have not fully assessed.

The OECD's work on AI and infrastructure notes that demand for AI-ready data centre capacity could triple by 2030. That projection reflects a significant and growing pressure on cloud migration decisions: organisations are accelerating migration timelines specifically to create AI-capable cloud platforms, often before the governance, data architecture, security controls, and operational maturity that AI workloads require are in place.

This creates a specific migration risk profile. The target environment is not just being built to run migrated workloads — it is being built to support AI programmes that have their own governance, data quality, infrastructure, and control requirements. A migration that creates an AI-capable platform before it is AI-governable produces a specific category of risk: ungoverned AI infrastructure that is difficult to secure, audit, and control after it has been built and relied upon.

The migration risk assessment question for organisations with AI ambitions is not just "is this environment ready for migration?" It is "is this environment ready to support AI safely and responsibly?" Those are related questions with overlapping but not identical answers.

What Good Migration Risk Management Looks Like

The Intelligence Pack describes a consistent set of risk maturity indicators that characterise high-performing migration programmes. Taken together, they describe what risk management looks like when it is working well rather than when it is catching up with problems.

A formal risk assessment workstream within migration governance — not a gate review, not a pre-migration checklist, but an ongoing programme function with owners, cadence, and update cycles. Clear wave sequencing logic that reflects security, compliance, sovereignty, and dependency constraints alongside technical complexity. Landing zone and governance foundations established and validated before sensitive or complex workloads migrate. Early cybersecurity integration and cross-functional governance that includes collaboration across vendors, internal teams, and compliance functions. Defined rollback, incident response, and operational readiness patterns that are tested through early waves before being relied upon at scale.

What these indicators have in common is a programme attitude: risk is not an obstacle to migration. It is a dimension of migration decision-making that, when assessed well, enables the programme to move with more confidence and fewer expensive surprises.

CloudFruition Insight: The goal of migration risk assessment is not to prevent migration. It is to enable migration to proceed with an accurate understanding of the risks involved and a governed plan for managing them. Organisations that assess risk well tend to migrate with more confidence and fewer programme pauses than those that assess it minimally and discover risks in execution.