Cloud adoption is not cloud maturity
About half of EU enterprises buy paid cloud services. Only one in seven uses the cloud to develop, test or deploy applications — and four questions tell you more about how well you operate it than any list of tools.
About half of EU enterprises now buy paid cloud services. Of the companies that do, 85.2% use the cloud for email — while only 26.1% use cloud platforms to develop, test or deploy applications. That second group is roughly 14% of all the enterprises covered by the survey: about one in seven.
isoc_cicce_use, 2025.This article is mainly for that one in seven: companies already building or running software in the cloud. If you are earlier in the journey, the same questions still apply — just at a simpler scale.
Moving infrastructure to the cloud changes where software runs. It does not automatically make that software easier to change, the infrastructure easier to understand, the bill easier to explain or production easier to operate.
That gap is what we mean by cloud maturity. It is less about which cloud services you use and more about whether your organisation can answer four practical questions.
1. Can a small change reach production safely and predictably?
A company we review can already have what looks like a modern delivery setup. Code goes through CI. Tests run automatically. Deployment is automated.
And yet releases are still painful.
Follow one real change from a developer’s machine to production and you may find something very different from the architecture diagram: a configuration value copied manually; an approval that routinely adds half a day; tests that are green but do not cover the integration where failures actually occur; a deployment that one engineer understands well enough to recover but the rest of the team does not; or a rollback procedure nobody wants to test during an actual incident.
The pipeline exists. The capability around it is incomplete.
How we approach it
When we review delivery, we do not start by asking what CI/CD tool is being used. We trace a real change end to end. Where does it wait? What happens manually? What could fail without a test noticing? What is different between environments? What happens when the deployment is wrong?
Then we work on the constraint. That might mean better integration tests. It might mean removing an approval. It might mean automating configuration or making rollback predictable.
The objective is not “more CI/CD”. It is:
A small change can reach production without drama, and the team knows quickly if something went wrong.
Check this yourself
Pick one ordinary change shipped in the last month. Measure how long it spent waiting versus how long somebody was actually working on it. Then list every point where a person had to remember, copy, approve or manually verify something.
That usually tells you more about your delivery capability than the pipeline diagram does.
2. Could another engineer recreate and explain the environment?
A different review often starts with infrastructure that works perfectly well — until somebody asks why it looks the way it does.
A development environment was created first. Production followed. Someone changed a permission directly in the console. A temporary resource became permanent. A credential was created for a one-off task. Two years later, nobody is confident enough to remove any of them.
Nothing is necessarily broken. The problem is that the infrastructure has accumulated more history than explanation.
How we approach it
Before talking about Infrastructure as Code, we ask simpler questions. Can we rebuild this environment if it disappears? Why does each important resource exist? Who owns it? Can access be added and removed deliberately? Are development and production different because they need to be — or because they drifted apart? Could another engineer understand the environment without finding the person who originally built it?
Once those answers are clear, Infrastructure as Code may be part of the solution. But Terraform, CDK or another tool is not the outcome. Reproducibility is.
A healthier environment is one the team can understand, review, recreate and change without depending on somebody’s memory.
Check this yourself
Choose one important environment and imagine it disappears tomorrow. Could the team recreate it from what is documented and version-controlled today?
If the answer is “probably, but we would need to ask X”, you have found something worth investigating.
3. Can you explain what the cloud costs — and why?
We sometimes enter a review because somebody has noticed one simple thing: the cloud bill keeps growing.
That is not necessarily a problem. If usage and revenue are growing, infrastructure spend may quite reasonably grow with them. The warning sign is when nobody can explain what changed.
A review may uncover non-production environments running permanently, oversized resources, forgotten storage, services with no clear owner, or several teams paying separately for variations of the same capability. None of them has to be spectacular. Cloud waste is often boring: it accumulates one reasonable-looking decision at a time.
How we approach it
We do not begin with discounts. First we establish visibility. Which services account for the spend? What changed month to month? Which costs grow with customer usage, and which do not? Who owns the resources? What can be switched off, resized or redesigned?
Only then does optimisation become meaningful. Sometimes the answer is lifecycle automation. Sometimes rightsizing. Sometimes architecture. Sometimes simply making cost visible to engineers when the decision is being made rather than three months later. This is where FinOps practices can help.
The useful outcome is not necessarily a lower number. It is being able to say:
We know what we are paying for, why it changed, who owns it and whether the cost makes sense for the value it supports.
Check this yourself
Take the five largest items on last month’s cloud bill. For each one: who owns it? What business workload does it support? Why did it cost that amount? What would happen if usage doubled?
If those answers require a research project, start there before trying to negotiate cheaper cloud.
4. Will the team notice the problem before the customer does?
This is the easiest question to make abstract, so use a very concrete test.
Imagine one of your important customer journeys becomes slow or starts failing. What is the first alert that fires? Is it an alert that tells the team something actionable — or is the first meaningful signal the same thing a customer would have called about?
We have seen systems with dashboards, logs and plenty of alerts where that distinction was surprisingly uncomfortable. Infrastructure metrics were being collected. The signals that represented an actual customer problem were not. The result was plenty of telemetry and very little warning.
How we approach it
We work backwards from failure. What would the customer experience? What should the team see before that happens? Which signal actually tells us the service is unhealthy? Who responds? What information do they need immediately?
From there, the answer might be better application telemetry, a different alert, a runbook, automated recovery or clearer ownership. Often it is less about adding monitoring than removing noise and measuring the right thing.
The goal is straightforward:
When something important degrades, the team sees the problem, understands enough to act and knows who owns the response.
Check this yourself
Open the last meaningful production incident. What told you about it first? Now ask what signal could have told you earlier.
That gap is usually more useful than counting dashboards.
Four questions, one underlying capability
These situations look different: slow releases; infrastructure nobody wants to touch; cloud spend nobody can explain; customers discovering failures first.
But they have something in common. The organisation is using cloud technology without yet having all the operating capabilities needed to use it confidently.
That is why we do not evaluate cloud environments by counting tools. We look for evidence that the organisation can change software predictably, understand and reproduce its infrastructure, connect cost to ownership and usage, and detect and respond to operational problems effectively.
That is a much more useful definition of cloud maturity than having moved workloads to AWS, Azure, GCP or another platform.
And this is why we don’t start with “you need DevOps”
DevOps can lead to CI/CD, Infrastructure as Code, observability, security automation, FinOps practices or platform engineering. Those are possible interventions. They are not the diagnosis.
We start with the constraint. Something takes too long. Something is difficult to reproduce. Something costs more than anyone can explain. Something fails without the right people knowing soon enough.
Then we trace the cause and choose the smallest intervention that materially improves the way the system is delivered or operated. Sometimes that is automation. Sometimes architecture. Sometimes ownership. Sometimes removing a process step rather than adding another tool. That is the shape of our DevOps and cloud work.
Cloud adoption tells you that the technology moved. Cloud maturity tells you whether your organisation can change it safely, understand what is running, explain what it costs and respond when something goes wrong.
If some of those questions produced uncomfortable answers, they are also a reasonable place to start improving things — whether you work through them internally or bring in outside help.
And if you want a second pair of eyes, our free 20-minute check starts with the same questions. If DevOps is part of the answer, we will say so. If it is not, we will say that too.
Source: Eurostat, 2025 EU survey on ICT usage and e-commerce in enterprises,
dataset isoc_cicce_use. The survey covers enterprises with at least 10 people
employed or self-employed in the sectors it reports on.