Cloud Maturity, 18 Months In

What cloud maturity genuinely looks like a year and a half after migration, versus what the vendor promised at the start

By Ed Berwick

At the start of most cloud migrations, the story is remarkably consistent.

The business case promises greater agility. Vendors showcase automated operations, self-healing infrastructure, lower costs, stronger security and near-limitless scalability. Executive presentations feature operating models that appear clean, efficient and largely frictionless.

Eighteen months later, most organisations discover that cloud maturity is something very different.

Not because the migration failed. Quite the opposite.

The reality is that the hardest part of cloud adoption begins after the workloads have moved.

The organisations making genuine progress are rarely the ones talking about migration percentages. They’re focused on operational discipline, engineering confidence and the ability to make good decisions quickly.

That’s what cloud maturity actually looks like.

The Migration Ends. The Real Work Starts.

In the early stages of a cloud programme, success is often measured by activity.

How many workloads have moved?

What percentage of applications are cloud-hosted?

How quickly are datacentres being decommissioned?

These metrics matter because they demonstrate progress against the migration plan. The problem is that they reveal very little about whether an organisation is actually becoming cloud-native in how it operates.

An organisation can have 90% of its workloads migrated and still struggle with outages, unpredictable costs, unclear ownership and inconsistent governance.

Likewise, an organisation that has migrated only a portion of its estate may be significantly more mature if it has developed strong operational practices around the services it has adopted.

Cloud maturity is less about where workloads run and more about how effectively teams manage them.

The Markers That Actually Matter

Eighteen months after migration, the most useful indicators are rarely the ones that appeared in the original business case.

Instead, maturity tends to reveal itself through a handful of practical signals.

Incident Response Becomes Predictable

Immature cloud environments often suffer from uncertainty during incidents.

Teams spend valuable time determining ownership. Diagnostic data exists but is fragmented. Escalation paths are unclear. Engineers know the tooling but lack confidence in the operating model.

As maturity develops, response becomes more structured.

Monitoring is trusted. Runbooks are current. Teams understand who owns what. Recovery times improve not because failures disappear, but because the organisation has learned how to manage them effectively.

The goal is not zero incidents.

The goal is reducing the time between detection, understanding and resolution.

Cost Conversations Become Routine

One of the most common post-migration surprises is cloud spend.

Early budgeting assumptions frequently collide with real-world usage patterns. Development environments remain active unnecessarily. Resource sprawl accumulates. Consumption grows faster than governance.

Mature organisations don’t necessarily spend less.

They simply understand where the money goes.

Business owners can see consumption patterns. Engineers understand the cost implications of design decisions. Finance teams receive visibility rather than surprises.

Cloud maturity is often the point at which cost management becomes operational rather than reactive.

Teams Stop Relying on a Handful of Experts

Every cloud programme has heroes.

Usually a small group of architects, consultants or senior engineers who understand the platform better than everyone else.

Early on, this expertise is valuable. Long term, it becomes a risk.

One of the strongest indicators of maturity is the spread of confidence across the organisation.

Teams can deploy safely. Troubleshooting knowledge is shared. Platform standards are understood by more than a select few individuals.

When cloud capability becomes institutional rather than individual, genuine maturity begins to emerge.

Governance Drift Is Identified Early

Governance is rarely a one-time exercise.

Policies established during migration gradually weaken as new projects arrive, priorities shift and teams find workarounds.

The most mature organisations are not those that avoid drift entirely.

They’re the ones that detect it quickly.

Tagging standards are monitored. Security baselines are validated continuously. Exceptions are visible and reviewed rather than quietly accumulating in the background.

Good governance becomes part of daily operations rather than an audit activity.

A Realistic Landing Point: An Anonymised Example

Consider a mid-sized organisation that completed a substantial public cloud migration eighteen months ago.

At programme kickoff, leadership expected multiple outcomes:

  • Reduced infrastructure costs
  • Faster application delivery
  • Increased automation
  • Improved resilience
  • Modernised ways of working

Eighteen months later, the results were mixed.

Infrastructure costs had not fallen dramatically. In fact, some areas had become more expensive than anticipated.

Automation existed, but not everywhere. Legacy applications still required operational intervention. Some teams embraced infrastructure-as-code while others continued to rely on manual processes.

Yet the organisation was unquestionably more mature than it had been before migration.

Major incidents were resolved significantly faster.

Platform ownership was clear.

Engineering teams deployed more frequently and with greater confidence.

Security visibility had improved.

Business units had access to meaningful cost reporting.

Most importantly, cloud decisions were becoming informed by operational experience rather than vendor guidance.

The programme had not delivered perfection.

It had delivered competence.

And that proved far more valuable.

What Good Really Looks Like After 18 Months

Perhaps the most damaging aspect of many cloud migrations is the expectation that transformation will be complete shortly after migration ends.

In reality, eighteen months is often still the early stage of operational maturity.

A healthy organisation at this point might look something like this:

  • Most critical workloads are stable in cloud environments.
  • Monitoring and observability are embedded into operations.
  • Cost data is trusted and regularly reviewed.
  • Security controls are largely standardised.
  • Platform ownership is understood.
  • Engineers are increasingly self-sufficient.
  • Governance is improving, even if inconsistencies remain.

Notice what’s absent from that list.

There is no claim of complete automation.

No promise of dramatic cost reduction.

No expectation that every legacy process has disappeared.

No assumption that every team operates at the same level of maturity.

Those outcomes may come later. Some may never arrive in the way originally imagined.

And that’s perfectly normal.

The Better Question

When organisations evaluate cloud progress, they often ask:

“Have we finished the migration?”

Eighteen months later, the more useful question is:

“Have we become better at operating in the cloud?”

That’s where maturity ultimately shows itself.

Not in how many workloads were moved.

Not in how closely reality matched the vendor slide deck.

But in whether the organisation has developed the operational habits, confidence and governance required to continuously improve.

Because successful cloud adoption isn’t a destination reached shortly after migration.

It’s a capability that gets built over time.

Share: X (Twitter) Facebook LinkedIn