Executive Clarity · Unfiltered: SAP Public Cloud — Issue 04

From Handcuffs to Sailboats

The European Commission's July 2026 decision did not weaken SAP's cloud strategy. It removed deadline pressure from the ERP decision — so architecture, not urgency, can decide the journey.

Originally published on LinkedIn in Unfiltered: SAP Public Cloud on 11 July 2026 — this is the canonical sapperment edition.

What Europe’s decision really means for SAP customers

Imagine standing on a harbour wall before sunrise.

You can hear the water. You can hear rigging knock against metal masts. You can hear engines warming somewhere beyond the fog.

But you cannot see the horizon.

For years, someone has stood beside you with a stopwatch.

Leave now. Weather is coming. The harbour will not stay open forever. That boat is your best option.

At some point, urgency begins to impersonate strategy. You stop asking where you actually want to go. You ask only how quickly you can get on board.

That is how many SAP customers have experienced the last several years. Their ERP conversations were often framed by maintenance milestones rather than business ambition: mainstream maintenance, extended maintenance, support premiums, migration factories, acceleration programs, and end dates.

Not because those issues were trivial. Because they were urgent. And urgency has a way of shrinking the field of vision.

Deadlines are excellent at creating movement. They are terrible at creating direction.

Executive summary

On July 9, 2026, the European Commission accepted legally binding commitments from SAP that change how customers can organize maintenance and support for on-premises ERP software. The immediate headlines were about support contracts. The more important consequence is architectural: many customers are no longer forced to make ERP decisions primarily under deadline pressure. They can make them under strategic discipline instead.

That does not mean SAP’s destination has changed. At SAP Sapphire 2026, the company doubled down on the Autonomous Enterprise, positioning SAP Business AI Platform, SAP Business Data Cloud, Joule, and SAP Business Technology Platform as the architectural foundation for AI-driven business operations. In SAP’s own language, AI agents must be anchored in “business processes, data and governance.” In other words, the cloud strategy did not weaken. It became easier to approach it on the customer’s terms.

For CIOs and CFOs, that changes the agenda. The first question is no longer, “How fast can we migrate?” It is, “What kind of operating model do we want to run ten years from now?” Public cloud, private cloud, hybrid architecture, and selective retention are all viable options in the right context. But each option carries different trade-offs in cost, governance, innovation velocity, and AI-readiness. Those differences should be assessed deliberately, not emotionally.

The view is straightforward: the future of SAP transformation will no longer be defined by deadlines. It will be defined by decisions. And the quality of those decisions depends on how quickly organizations can move from assumptions to evidence — from fog to facts.

The Deadline Trap

If you want to understand why the European Commission’s decision matters, you have to start with the trap it interrupted.

In February 2020, SAP committed to support SAP S/4HANA through the end of 2040. At the same time, it confirmed mainstream maintenance for SAP Business Suite 7 core applications through the end of 2027, followed by optional extended maintenance through the end of 2030. Those dates were clear. They were also powerful. In thousands of boardrooms, they became the frame through which “ERP transformation” was discussed.

That framing had two consequences.

First, it created movement. Deadlines always do. Programs were funded. Readiness checks were launched. Transformation offices were built. System integrators built delivery factories around conversion paths.

Second, it compressed strategy into schedule. The conversation became less about which capabilities truly differentiated the enterprise and more about whether the organization could clear the runway in time.

SAP itself did not present cloud adoption as a one-size-fits-all jump. Its Support Portal has long described the Cloud Extension Program as a way to move “at their own pace,” and it explicitly acknowledges cloud, on-premises, and hybrid pathways. That matters, because it shows the market narrative was always narrower than the menu of options SAP formally described.

Still, pressure changes behavior. A company facing 2027 and 2030 milestones does not naturally begin with a philosophical discussion about future operating models. It begins with implementation math: custom code volume, data quality, integration count, resource availability, and budget cycles.

That is understandable. It is also dangerous.

Because migration is an activity. Architecture is a decision.

And when the activity comes first, the decision is often made by default.

The Day Everything Changed

Then Brussels intervened.

On July 9, 2026, the European Commission accepted a set of legally binding commitments from SAP covering maintenance and support for on-premises ERP software. The changes were practical and specific: an alternative method for calculating licence fees, the elimination of reinstatement fees, and reduced back-maintenance fees for customers who had previously left and wanted to return. SAP confirmed the commitments would apply globally, across all on-premises products, to all current and future customers — for ten years.

That is the legal story.

The Commission did not make cloud less attractive. It made architecture more important. Here is why: for years, maintenance deadlines and switching costs had been doing hidden work in the market. They had been narrowing the conversation before it even started. Once that pressure eased, the number of credible transformation paths expanded — immediately, and without anyone needing to change a single line of code.

The point is not that customers should stay where they are.

The Commission’s own investigation tells you what was really at stake. When formal proceedings opened in September 2025, the concern was not cloud adoption rates or product strategy. It was whether SAP’s practices may have restricted competition in the aftermarket for maintenance and support — leaving customers with fewer choices and higher costs than a well-functioning market would allow. That is a customer-choice case. And customer choice, once restored, changes how architecture gets decided.

SAP’s public response is equally instructive. The company described the commitments as providing “greater clarity, choice and safeguards for customers managing complex on-premise environments.” Not anti-cloud language. The language of managed transition.

The timeline, briefly:

  • September 2025 — European Commission opens formal antitrust proceedings
  • July 9, 2026 — Commission accepts SAP’s commitments; changes take effect globally
  • Now — Every active SAP transformation programme operates in a different decision environment

The practical implication is subtle but profound. A transformation programme that begins in 2026 no longer has to open with the sentence “We have no choice.”

It can start with a better one:

What are we actually trying to become?

Cloud Was Never the Destination

It is tempting to read this moment as a setback for SAP’s cloud strategy.

It is not.

SAP Sapphire 2026 suggests the opposite. SAP is not investing as though cloud ERP were the finish line. It is investing as though cloud ERP were the foundational layer underneath something considerably larger: a platform-centred model for AI-driven business operations.

The Sapphire Innovation News Guide describes the Autonomous Enterprise as a combination of Joule Work, SAP Autonomous Suite and SAP Business AI Platform — available in public or private cloud ERP. SAP’s announcement describes the Business AI Platform as unifying SAP BTP, SAP Business Data Cloud and SAP Business AI into a single governed environment, with SAP Knowledge Graph at its core.

That sentence changes the frame entirely.

Cloud was never the destination.

It was the runway. Runways don’t exist to be admired. They exist so something bigger can take flight.

For years, ERP modernisation was discussed as though the target state were simply a newer transactional core. SAP’s 2026 messaging says otherwise. The real architecture is layered:

  • A cloud ERP core — the trusted foundation for business data and processes
  • An integration and extension platform — SAP BTP, connecting and extending without modifying the core
  • A unified data layer — Business Data Cloud, creating context across systems and boundaries
  • An AI layer — capable of reasoning and acting with real business context, not just pattern-matching on generic data

Each layer depends on the integrity of the one below it.

Which is why the EU decision and SAP’s AI ambition are not in tension.

They are the same story, told from two different directions.

Choosing the Right Sailboat

More options do not make the decision easier.

They make the decision more important.

That is why this moment demands a framework, not a product pitch.

In one recent landscape review, a single SAP system contained 847 custom developments.

In a mature ECC landscape, 847 developments isn’t a warning sign. It’s a Tuesday.

The interesting number wasn’t 847. It was what happened next.

When every development was challenged with one question:

“What business advantage disappears if we remove this?”

the conversation changed completely. Architecture stopped being technical.

It became economic.

What matters is what happened when the list was reviewed.

Only a minority of those developments mapped clearly to differentiated business capability. Some reflected regulatory requirements that had since changed. Some supported processes the business had quietly abandoned. Some solved product gaps from a decade earlier that SAP had long since closed. Some duplicated functionality available elsewhere in the same landscape.

A few were genuinely strategic.

Most were simply inherited.

Every custom object asks the same question:

Why does this exist?

That question gets asked too late in almost every transformation programme I have seen. It belongs at the beginning — before deployment models are discussed, before vendors are invited to present, before the project charter is written.

Because the answer determines almost everything that follows.

Comparing the Options

Before selecting a deployment model, it is worth comparing the realistic operating-model options with more discipline than most ERP projects historically apply. The assessment in the original edition reflects an editorial view, inferred from SAP’s deployment characteristics, lifecycle commitments and platform strategy. It is not a universal benchmark — local complexity, industry regulation and organisational change readiness all shift the picture. (The full operating-model comparison table appears in the original LinkedIn edition.)

No option in that comparison is the right answer. Every column describes a trade-off, not a verdict. The right option depends on what you are actually trying to become — which is why the comparison should follow the conversation, not start it.

Five Questions That Matter More Than Any Demo

Before a deployment model is chosen, five questions belong at the centre of the discussion.

1. Which processes truly differentiate the business? Not every process needs to be excellent. Most simply need to work. Identifying the ones that genuinely create competitive advantage is the first act of architectural discipline — because those are the processes worth protecting, and everything else is a candidate for standardisation.

2. Which custom developments still create measurable value? The 847 question. If a development disappeared tomorrow, would customers notice? Would the business lose revenue or market position? If the honest answer is no — it has already become technical debt. The only remaining question is when to retire it.

3. Where should future innovation happen? Inside the ERP core? On SAP BTP? In adjacent applications built for a specific capability? Or nowhere at all, because the process it would support is not worth automating? This question determines Clean Core strategy more directly than any vendor guideline.

4. What level of process standardisation is economically worth pursuing? Standardisation is not free. It requires organisational change, retraining and often political negotiation across business units. The economic case needs to be made explicitly — not assumed.

5. What should the company look like in ten years — not its ERP system? This is the question that reframes every other answer. Technology choices should follow business strategy. When they lead it, programmes tend to deliver systems that nobody asked for, solving problems the business has already moved past.

Every transformation begins twice.

First in the boardroom, where the right questions either get asked or get avoided. Then in the project plan, which faithfully executes whatever was — or wasn’t — decided above. The distance between a good transformation and an expensive one is rarely technical.

It is almost always the quality of the conversation that happened before the first slide was shown.

From Fog to Facts

I want to be direct about what a transformation partner actually does — because “transformation partner” has become one of those phrases that means everything and nothing.

What we do is sequence.

We call it From Fog to Facts. Not because it sounds good. Because it describes the order in which decisions have to be made if they are going to hold up.

Step one is visibility.

Before anything else, I need to know what is actually there. Not what the documentation says. Not what the system diagram from 2019 shows. What is running, what is used, what is owned, and what is quietly holding the landscape together in ways nobody has written down.

That means establishing a factual baseline: process variants, custom code inventory, interface topology, integration criticality, data quality constraints, unused assets, and — most importantly — the real business ownership of every deviation from standard.

That last part is harder than it sounds. Systems accumulate history. The person who requested a particular workflow eight years ago may have left the company. The regulation that triggered a custom report may have changed. The business unit that owns an interface may no longer run the process it was built for.

Visibility is not a technical exercise. It is an archaeological one.

Step two is classification.

Not all complexity is bad. Some complexity is exactly where a company earns its margin — a pricing model that competitors cannot easily replicate, a supply chain capability built over decades, an industry-specific workflow that genuinely differentiates the business.

The job is to separate that from what I call historical sediment: complexity that accumulated not because it was strategic, but because nobody stopped to ask whether it still needed to exist.

In practice, that means sorting every feature, object, report, interface and workflow into one of four buckets.

Keep — because it creates real competitive advantage and belongs in the future architecture.

Retire — because it solves a problem that no longer exists, or duplicates something available in standard.

Relocate — because it is valid business logic, but it belongs on SAP BTP or in a specialised application rather than inside the ERP core.

Redesign — because the underlying need is genuine, but the current implementation is the wrong answer to it.

That classification is where most programmes skip ahead too quickly. They treat it as a discovery phase that feeds a migration plan. We treat it as the decision that determines whether the migration plan makes sense at all.

Step three is target architecture.

Only once the landscape is understood does the deployment model become a meaningful conversation.

Public cloud becomes genuinely attractive where standardisation is a feature rather than a compromise — where the business benefit of continuous innovation, reduced technical debt and AI readiness outweighs the cost of process change.

Private cloud becomes the right answer where process breadth, localisation requirements or the need for controlled flexibility remain essential to how the business actually operates.

Hybrid becomes valid when business sequencing matters more than ideological purity — when some domains are ready to move and others are not, and pretending otherwise just creates risk.

And selective retention can be rational — provided the time created by the Commission’s decision is used to improve the eventual choice rather than simply postpone it.

That distinction matters. Extra time can be wasted or invested. The organisations I respect most will use it to reduce avoidable complexity, improve the quality of their evidence, and arrive at a target state that genuinely fits both their economics and SAP’s platform direction.

Step four is platform design.

This is where I see the most expensive mistakes made — and where the mistakes are least visible until it is too late.

SAP BTP is not an integration afterthought. It is not the thing you configure after the ERP decision is “done.” SAP’s own positioning makes this clear: BTP capabilities now sit at the core of the Business AI Platform, and Integration Suite is central to connecting SAP and non-SAP landscapes at scale.

That means extension strategy, eventing, API governance, workflow automation and AI orchestration need to be designed early — as part of the architecture conversation, not appended to the project plan six months into implementation.

The organisations that treat BTP as a day-two consideration tend to arrive at go-live with a modern ERP core and a legacy integration layer underneath it. They have solved the wrong problem.

Step five is roadmap sequencing.

A mature roadmap does not say “migrate.” That word does not tell you enough.

It sequences value. First, stabilise the data — because everything that follows depends on trusting it. Then simplify the core, retiring and relocating complexity before it gets carried forward. Then move the right domains in the right order, based on business readiness rather than technical convenience. Then stand up the platform layer so that extensions, integrations and workflows land in the right place from the start. Then activate AI — but only where process discipline and data trust are already strong enough to support it.

AI on top of poor data is not intelligence. It is confident misinformation at scale.

It’s simply the sequence we’ve seen repeatedly produce better decisions.

  • Visibility.
  • Classification.
  • Architecture.
  • Platform.
  • Roadmap.

Always in that order. That is what From Fog to Facts means in practice.

Whenever organisations reverse that sequence, they usually end up rebuilding decisions they thought they had already made.

The harbour looks different today

Let’s return to the harbour.

For a long time, it looked as though there were only two choices: leave immediately, or risk being left behind.

Today, the harbour looks different.

But the harbour never really changed.

The fog did.

For a long time, we believed there was only one journey because it was the only one we could see.

Today, the horizon looks different.

There are more boats. There are more routes. There is more weather to read. And there is more responsibility on the captain.

The European Commission did not rewrite SAP’s strategy. SAP still sees the future in cloud ERP, platform-based integration and extension, governed business data, and AI agents anchored in process and policy. Sapphire 2026 made that unmistakably clear.

What changed is the customer’s freedom to choose the journey with more intent.

That is a bigger change than the maintenance headlines suggest. Because history rarely remembers the contractual detail that triggered a market shift. It remembers the decision-making standard that followed.

The winners of the next decade will not necessarily be the companies that move first.

They will be the companies that choose wisely.

And wise choices in enterprise architecture are almost never made in fog.

Sources and further reading

The perspectives in this article combine publicly available information with experience from SAP transformation programmes. Unless otherwise stated, strategic conclusions represent the opinion of the author.

For the architectural side of SAP transformation — SAP Signavio, SAP LeanIX, business process management and enterprise architecture — see Tobias Unger, whose work complements many of the concepts discussed here, especially around understanding your current landscape before deciding on the right transformation path.