Ask ten organizations how mature their cloud adoption is and most will answer with a percentage of workloads migrated. That number matters, but it says little about whether the cloud is actually delivering value. An organization can run almost everything in the cloud and still struggle with runaway costs, inconsistent security, slow provisioning and teams that depend on a handful of experts. Another can run a modest share of its estate in the cloud while doing so efficiently, safely and with genuine business impact.
This article offers a practical maturity model for cloud adoption that looks beyond migration counts. It draws on the structure of the major cloud adoption frameworks, adds the capabilities that have become essential since 2024, and looks ahead to what mature adoption will likely mean between 2027 and 2030. Use it as a self-assessment, a conversation starter with leadership, or the backbone of your next cloud roadmap.
Why a New Maturity Lens Is Needed
The major frameworks remain a solid foundation. The AWS Cloud Adoption Framework organizes capabilities into six perspectives (Business, People, Governance, Platform, Security and Operations) and describes the transformation journey as four iterative phases: Envision, Align, Launch and Scale. AWS stresses that you do not need to tackle all foundational capabilities at once and can evolve them as you move through the journey. Google’s Cloud Adoption Framework centers on four capabilities, which it calls learn, lead, scale and secure, and emphasizes balancing change across people, process and technology. Google also highlights a useful tension: cloud-native companies may move fast without enough guardrails, while enterprises new to the cloud may over-invest in governance design while moving too few workloads.
What has changed is the set of capabilities that separate leaders from laggards. Since these frameworks were first published, several themes have moved from optional to essential: AI workloads and agents, FinOps as a discipline, digital sovereignty, operational resilience regulation, platform engineering and sustainability reporting. A useful maturity model needs to account for them.
Cloud maturity is not how much you have moved. It is how reliably the cloud turns business intent into safe, economical, running software.
The Five Maturity Levels
The model uses five levels. They are deliberately described in terms of behavior rather than technology, because the same tools can be used well or badly.
- Level 1 – Exploratory: cloud use is driven by individual teams or projects. There is little shared governance, accounts or subscriptions are created ad hoc, and costs are discovered after the fact.
- Level 2 – Foundational: a landing zone exists, identity is centralized, and basic policies and tagging are defined. A central team does most of the work and approves most requests manually.
- Level 3 – Standardized: golden paths, infrastructure as code and policy as code are used for most new workloads. Cost is allocated and reviewed. Security and operations are consistent across environments.
- Level 4 – Optimized: workload teams are largely self-sufficient within automated guardrails. Unit economics, reliability objectives and security posture are measured and improved continuously. Exceptions are rare and tracked.
- Level 5 – Adaptive: the cloud operating model adjusts quickly to new technology, regulation and business models. AI-assisted operations, sovereignty controls and portability options are built in. Cloud decisions are made primarily on business outcomes.
Most organizations are not at a single level. It is common to see Level 4 security alongside Level 2 cost management. That unevenness is precisely what the model should reveal.
Eight Dimensions to Assess
The eight dimensions below combine the classic framework perspectives with newer concerns. For each, a few diagnostic questions help place you on the scale.
1. Strategy and business value
Is there a cloud strategy linked to measurable business outcomes, and is value tracked after migration? At low maturity, the business case is a one-time document. At high maturity, value realization is reviewed regularly, and cloud investments are prioritized against business objectives in the way AWS describes in its Envision phase.
2. People, skills and operating model
Who does the work, and how dependent are teams on a central group? Mature organizations have clear roles for platform, governance, FinOps and workload teams, a skills program with role-based learning paths, and enablement that steadily reduces dependence on experts.
3. Governance and compliance
Are policies documented, encoded and monitored automatically? Do exceptions have owners and expiry dates? Can you show an auditor or regulator how controls work and how they are evidenced? Mature governance is mostly invisible to teams because it is built into the platform.
4. Platform and engineering
How long does it take a team to go from idea to a production-ready environment? Mature platforms offer self-service golden paths, use infrastructure as code throughout, and are managed as internal products with backlogs and adoption metrics.
5. Security and identity
Is identity the primary control plane? Are human and non-human identities, including service accounts and AI agents, governed with least privilege? Is posture monitored continuously and are findings remediated against defined timelines?
6. Operations and resilience
Are service level objectives defined for critical services? Are recovery strategies tested rather than assumed? Mature organizations align resilience design with regulatory expectations where relevant, such as operational resilience rules in financial services, and practice recovery regularly.
7. Financial management
Is spend allocated, forecast and tied to unit economics? Are commitments managed actively? Is AI spend, including GPU capacity and model usage, governed with the same rigor as other cloud spend?
8. Data, AI and sustainability
Is the data platform governed and ready to support AI use cases? Are AI workloads deployed through approved paths with evaluation, logging and access controls? Is cloud carbon data captured and allocated for reporting? This dimension is the one most likely to separate organizations between 2027 and 2030.
Quick Reference: What Each Level Looks Like in Practice
Abstract level descriptions are easy to argue about. Concrete indicators make scoring faster and more consistent. The following examples show typical evidence at three points on the scale for a few of the dimensions.
- Platform, Level 2: new environments are requested by ticket and built by a central team, often taking weeks. Level 3: most environments are created from infrastructure-as-code templates within days. Level 4: teams provision standard environments themselves in hours through a self-service portal or pipeline, with guardrails applied automatically.
- Financial management, Level 2: a monthly invoice is reviewed by finance, with partial allocation. Level 3: most spend is tagged and allocated, and teams see their own costs. Level 4: teams track unit costs, forecasts are within an agreed tolerance and commitment coverage is managed deliberately.
- Operations, Level 2: monitoring exists but alerts are noisy and recovery plans are documents. Level 3: critical services have objectives and runbooks. Level 4: recovery is tested on a schedule, incidents feed improvement backlogs and automation handles routine remediation.
- Data and AI, Level 2: AI pilots run in isolated accounts with ad hoc data access. Level 3: an approved golden path exists for AI applications, with logging and access controls. Level 4: AI workloads have evaluation pipelines, cost budgets and governed data products behind them.
Teams can extend this reference for the remaining dimensions. The act of writing indicators down is itself valuable, because it forces agreement on what good looks like before scores are debated.
Running a Self-Assessment
A maturity assessment is useful only if it is honest and leads to decisions. A lightweight approach works better than a months-long audit.
- Assemble a small panel that includes platform, security, finance, operations and at least two workload team leads. A model scored only by the central cloud team will flatter it.
- Score each dimension on the five-level scale with a short written justification and one piece of evidence, such as a metric, a policy or a dashboard.
- Validate with data where possible: lead times, allocation coverage, policy compliance rates, recovery test results and exception counts.
- Agree target levels for each dimension over the next 12 to 24 months. Not every dimension needs to reach Level 5; the target should reflect business priorities and risk.
- Identify the binding constraint. Usually one or two dimensions hold back everything else. Low financial maturity, for example, can stall AI adoption because leaders cannot predict its cost.
- Build a roadmap with a handful of initiatives per quarter, each linked to the dimension and level it improves.
- Reassess every six to twelve months.
Turning scores into a roadmap
The AWS framework’s four phases offer a helpful way to sequence improvement work even for organizations well into their journey. For each initiative, briefly envision the business outcome it serves, align the stakeholders and capability gaps involved, launch a pilot with one or two willing teams, and scale only once the pilot has shown value. This rhythm prevents a common failure in which an assessment produces a long list of initiatives that all start at once and none finish. Limiting work in progress to three or four improvement initiatives per quarter is usually more productive than launching a dozen.
What Maturity Will Mean Between 2027 and 2030
Forecasting technology is risky, but several trends are already visible in provider roadmaps, regulation and industry practice. These are the capabilities that will most likely define Level 4 and Level 5 maturity over the next few years.
- AI-assisted operations as normal practice. Each major provider now offers AI assistants or agents for cloud operations. Mature organizations will define where these agents may act autonomously, where they need approval and how their actions are audited.
- Agents as governed workloads and identities. AI agents will be treated as first-class workloads with their own identities, permissions, budgets and monitoring, not as experimental side projects.
- Sovereignty and portability by design. Regulation such as the EU Data Act and sector-specific resilience rules is pushing organizations to document exit strategies, data location and switching options. Mature organizations will build these considerations into architecture decisions rather than retrofitting them.
- Unified cost and carbon data. Cost, usage and emissions data will increasingly be governed together, with standard schemas making multi-provider analysis easier.
- Continuous compliance evidence. Rather than preparing for audits, mature organizations will generate compliance evidence automatically from policy engines, logs and infrastructure code.
- Platform engineering as the default delivery model. Self-service internal platforms will be the norm, with the central cloud team focused on platform products rather than tickets.
A Hypothetical Assessment
Consider a hypothetical logistics company that has migrated around 70 percent of its applications over four years. Leadership assumes it is a mature cloud adopter. A one-day assessment workshop scores it as follows: strategy at Level 2 because benefits were never tracked after the business case; platform and security at Level 3 thanks to a solid landing zone and policy as code; operations at Level 3 with defined objectives for critical services but untested recovery plans; financial management at Level 2 with only partial allocation; and data, AI and sustainability at Level 1, with several AI pilots running outside the landing zone and no carbon data.
The binding constraint is clearly financial management and AI governance. The resulting 18-month roadmap prioritizes enforced tagging and monthly cost reviews, a golden path for AI applications with an approved model gateway, a quarterly recovery test program and a simple benefits tracking process for the top 20 applications. The company decides not to pursue Level 5 in any dimension yet, because its business priorities do not justify the investment.
Common Pitfalls
- Equating migration percentage with maturity. It is one input, not the outcome.
- Scoring by aspiration. Score what is true today and supported by evidence.
- Chasing Level 5 everywhere. Over-investing in governance at the expense of progress is a pattern Google explicitly warns about.
- Treating the assessment as a one-off. Maturity drifts backward without attention, especially when teams and technologies change.
- Ignoring AI and data. These dimensions are evolving fastest and will increasingly drive business value and risk.
Conclusion
A good maturity model makes uncomfortable truths visible and turns them into priorities. The frameworks from AWS and Google provide a solid structure, but the capabilities that matter have expanded to include AI governance, FinOps, sovereignty, resilience and sustainability. Assess your organization across all eight dimensions, focus on the one or two that constrain everything else, and set realistic targets for the next two years. Between 2027 and 2030, the organizations that benefit most from the cloud will be those whose operating model can adapt quickly, not simply those that moved the most workloads.
How Hanoi Technology Can Help
Hanoi Technology runs cloud adoption assessments and turns the results into practical roadmaps, delivered as projects, dedicated teams or managed services.