State of Cloud 2025: Navigating EMEA's Cloud Revolution

The least useful cloud question in 2025 is still the one that appears first in most slide decks: should we move to the cloud?

Most established organisations already have. The decision is now workload by workload. Which services need global reach? Which carry data-location or latency constraints? Which are kept in a provider because of a genuine operating advantage, and which remain there because no one has priced the cost of leaving?

EMEA makes that question harder, not simpler. A workload may have customers in multiple markets, data obligations in another, an operations team in a third, and a commercial commitment negotiated years before the AI requirement appeared. Treating that as one “cloud strategy” hides the trade-offs that matter.

Classify the workload before choosing the location

Cloud placement should begin with demand shape and dependency, not provider preference.

A batch reporting job that runs overnight, depends on a large internal data set, and can tolerate delay has different requirements from a customer-facing recommendation request. The latter may be sensitive to round-trip time, regional data handling, model size, peak concurrency, and the cost of moving data to the model. A static campaign site is different again: it benefits from broad distribution, but does not need its account state copied everywhere.

The point is not that every application belongs at the edge. It does not. The point is that a centralised answer and a distributed answer solve different workload problems. Good architecture makes the conditions visible rather than turning placement into ideology.

Multiple cloud is not multi-cloud

Many organisations use more than one provider. That fact alone does not make them portable.

Multiple cloud often means that a business unit chose a service, acquired a company, or met a regional requirement. The result can be perfectly rational. Multi-cloud, in the stronger sense, means that a workload can move with an understood cost, a realistic time frame, and a team capable of operating it somewhere else.

Those are not the same thing. Portability has a price: interfaces to redesign, data to move, identity and observability to reconnect, resilience tests to repeat, and people to support the new operating model. A strategy that ignores those costs is not reducing lock-in. It is postponing the invoice.

AI changes the economics before it changes the application

AI initiatives are often introduced as a feature discussion: personalisation, automation, forecasting, assistants. The infrastructure question arrives soon afterwards.

Inference has a demand profile. It consumes model capacity, moves data, needs a response-time target, and can trigger an expensive fallback when a request misses the intended route. Training, batch enrichment, retrieval, and real-time interaction should not be bundled into one “AI workload” label. They have different cost curves and different placement options.

The first useful control is visibility. Attribute inference activity to a product, team, feature, or customer journey before debating commitment discounts or new hardware. Without that, a leadership team cannot tell whether a model is improving an operating outcome or simply creating a larger bill with a better demo.

Modularity is an operating commitment

Breaking a large application into smaller services can improve release independence. It can also create more calls, more identities, more failure paths, more telemetry, and more people needed to understand what happens when a request spans them.

The decision should follow a constraint. Split a component when it has a different scaling profile, release cadence, ownership boundary, or data location requirement. Do not split it because modularity is described as maturity. A distributed system is not a more advanced monolith; it is a different operational burden.

Open-source components can help preserve choice, but they do not remove that burden either. They transfer some responsibility from a provider contract to an internal team: patching, compatibility, operating expertise, and a plan for when a dependency changes direction.

What to do on Monday morning

Pick the five workloads that drive the most customer impact, spend, or regulatory exposure. For each one, document the demand shape, data location, latency tolerance, current commercial commitment, exit cost, and accountable owner.

That is the beginning of a cloud strategy that can survive the next planning cycle. It does not promise a universal migration, a universal saving, or a universal architecture. It gives the organisation a way to make the next placement decision with its eyes open.