From Lift-and-Shift to Cloud-Native: The Cloud Maturity Journey

Most organisations now run at least some of their technology in the cloud. Far fewer get the benefits they expected. A common story goes like this: workloads are moved quickly to meet a data centre exit date, the monthly bill turns out higher than the old hosting costs, and the promised speed and resilience never quite arrive.

That story is not a failure of the cloud. It is what the first stage of cloud maturity usually looks like. Understanding the typical journey helps you set realistic expectations, spot where you are stuck and decide what to work on next.

Stage 1: Lift-and-shift

In the first stage, existing applications are moved to cloud infrastructure with as little change as possible. Virtual machines replace physical servers; the architecture, processes and team structures stay largely the same.

What it looks like:

• Servers are created by hand through the provider's console, often by a small infrastructure team.
• Applications are sized for peak load and run around the clock.
• Security and network designs mirror the old data centre.
• Costs arrive as a single large bill that few people understand.

Why organisations start here: it is fast and low-risk, and it is often the only realistic option when a data centre contract is ending. Rehosting is a perfectly sensible first step.

The trap: many organisations stop here. They pay cloud prices for a data centre operating model, and conclude that the cloud is expensive and no faster than before.

Stage 2: Cloud-enabled

In the second stage, organisations start to use what the cloud is good at. Managed services replace some self-managed components, infrastructure is defined as code, and teams begin to take responsibility for cost and reliability.

What it looks like:

• Environments are built from templates or code rather than by hand, so they can be recreated reliably.
• Managed databases, storage and messaging services replace some home-grown equivalents.
• Resources are tagged by team or product, and costs are reported back to the people who create them.
• Basic automation handles scaling, backups and patching.
• Security baselines are defined and checked automatically.

The shift: the biggest change at this stage is not technical. It is operational. Teams stop treating infrastructure as something another department provides, and start treating it as part of what they build and run.

Stage 3: Cloud-native

In the third stage, the cloud shapes how systems are designed and how teams work. New applications are built to take advantage of elastic, managed and distributed services from the start, and the organisation has the practices to run them well.

What it looks like:

• Systems are designed to tolerate failure: a single server or availability zone can disappear without customers noticing.
• Teams can provision what they need through self-service, within guardrails that enforce security and cost policies automatically.
• Cost is treated as a design decision, with teams able to see the cost impact of their choices.
• Deployments are frequent, small and automated.
• Security is built into pipelines and platform defaults rather than checked at the end.

Not every workload needs to reach this stage. A stable internal application that rarely changes may be perfectly well served by a simple lift-and-shift. Maturity is about having the capability to build and run cloud-native systems where they add value, not about rebuilding everything.

Six dimensions of cloud maturity

It helps to look at cloud maturity across several dimensions, because organisations rarely progress evenly. The Cloud Maturity assessment uses six:

1. Strategy and governance. Is there a clear reason for using the cloud, with decisions about what goes where?
2. Migration and adoption. How deliberately are workloads assessed and moved?
3. Architecture and design. Are systems designed for the cloud, or simply relocated to it?
4. Operations and reliability. Is the environment automated, observable and resilient?
5. Security and compliance. Are controls built into the platform, or added by hand?
6. Cost management and optimisation. Do teams understand and control what they spend?

A common profile is strong migration and adoption, weaker architecture, and weakest cost management. That pattern usually means workloads moved quickly without the practices to run them efficiently.

Security matures on its own path

Cloud security deserves particular attention, because the risks change shape in the cloud. Identity becomes the main perimeter, misconfigurations become a leading cause of exposure, and the speed of change means manual reviews cannot keep up.

Organisations at the lift-and-shift stage of security often apply data centre controls to cloud environments: firewall rules copied across, broad administrator access, and periodic manual checks. As they mature, they move towards least-privilege identities, configuration checks that run automatically, and guardrails that prevent insecure resources from being created in the first place.

Because security can lag behind adoption, it is worth assessing separately. The Cloud Security assessment covers identity and entitlements, workload protection, configuration and posture, data security, network security, and detection and response.

How to move forward

A few principles help organisations progress:

• Fix the operating model before re-architecting. Infrastructure as code, tagging and cost visibility are cheap and unlock almost everything else.
• Pick a lighthouse workload. Rebuild one meaningful application in a cloud-native way and use it to develop skills and patterns before scaling.
• Make cost visible to engineers. People manage what they can see. Showing teams the cost of their environments often reduces waste quickly.
• Build guardrails, not gates. Automated policies that prevent risky configurations let teams move fast safely, instead of waiting for manual approvals.
• Retire as you go. Every migrated workload should prompt the question, "Do we still need this at all?"

Frequently asked questions

Is lift-and-shift a mistake?

No. Rehosting is often the right first step, especially when time is short. It becomes a problem only if the organisation stops there and expects cloud benefits without changing how it works.

How long does it take to become cloud-native?

For most established organisations, building genuine cloud-native capability takes several years, and many will always run a mix of approaches. The aim is to build the capability where it adds value, not to convert everything.

What is the quickest win in cloud maturity?

Cost visibility. Tagging resources by owner and reporting costs back to teams typically reveals idle and oversized resources that can be removed or right-sized straight away.