Last week, we attended SAP Sapphire Madrid. The headline news had mostly landed two weeks earlier at the flagship Orlando event – including the launch of the SAP Business AI Platform, the SAP Autonomous Suite with 50+ Joule Assistants, and its partnerships with Anthropic and Nvidia.
But the more interesting stories came from the conversations we had in IFEMA’s vast thoroughfares, from seeing what other vendors are building in the background, and from the gaps in SAP’s own narrative.
Three things in particular stood out.
Software is converging
The technology and solutions enterprises once bought in separate boxes are merging into one stack - ERP, data warehouses, BI, integration platforms, AI tools, and agent frameworks - all consolidated. SAP's Business AI Platform announcement is a clear example of this, with SAP Business Technology Platform (BTP), SAP Business Data Cloud, and Business AI, all folded into one offering. Every serious vendor is making the same move.
What’s emerging is a single layer that holds the enterprise’s data, its model of how the business runs, its AI and agents, all in one place. This layer goes by different names – you’ll know it as the context layer, the business AI platform, or the intelligent data platform – but the end result is the same.
Convergence is happening because the alternative doesn’t scale. A separate AI tool for every workflow, sitting on top of a data architecture nobody really controls, produces a backlog of integration debt, which in turn leads to cost and drag. Customers we speak to are tired of it, so it makes sense that the market is consolidating around the layer where data, model and action sit together.
Ontology is the engine
But what makes this layer work? The answer to this question, which Palantir pioneered over a decade ago, and which is now becoming consensus across the industry, is the ontology.
An ontology is a business-readable model of the enterprise. It sits above the raw tables and below the user interface, mapping every customer, material, vendor, journal entry, and plant, with the relationships between them and the actions that can be performed on each. It is what turns a data warehouse into a system the business can reason about, and what turns an agent from a chat assistant into something that can operate the business.
Without an ontology, agents are just foundation models with prettier UIs. They can write summaries and answer questions, but they can’t act on the entities a business runs on because they don’t have sight of them. With an ontology, the same agents can merge two business partners, post a journal entry or approve a purchase order, all with provenance, governance, and an audit trail.
With all SAP's talk of "context", "knowledge graph", and "semantics", each a fragment of what an ontology actually is, they are making all the right noises without quite naming the solution. They're describing the right substrate. This is where platforms like Palantir’s Foundry and AIP have a head start, already treating the ontology as the primary surface area for both data and action.
FDEs are going mainstream
The third thing worth noting is the delivery model. The forward-deployed engineer pattern – invented by Palantir – describes small teams embedded inside the customer, building on the platform in real time, and learning the business as they build.
It was clear from our conversations at Sapphire that this FDE model has spread far beyond the realms of Palantir, such that it is now part of the broader enterprise software vocabulary. Several vendors are positioning their delivery as FDE-style, even where the underlying platform is not really set up for it.
The shift makes sense. The old model of selling licences before handing off to a system integrator to deliver in waterfall against a fixed scope was always going to break down when the thing being delivered evolved into an agent-driven, ontology-modelled environment. Software that learns the business needs people – or FDEs – who learn the business alongside it.
The hole in SAP’s migration story
This all brings us to the gap in SAP’s narrative.
SAP has launched a suite of AI assistants this year as part of its Autonomous Suite. Joule Studio 2.0 lets customers and partners build their own. Joule Assistants now exist for cloud migration, ABAP remediation, business-process redesign, go-live monitoring, financial close, and supply chain planning. All of these examples offer real value.
But what they don’t add up to is a migration operating system or central coordination layer. In practice, this would be a single substrate that holds the legacy ECC estate, the target S/4HANA model, business rules, compliance posture and workstream gates in a single ontology with agents acting across it, under human direction.
Palantir describes this approach as the Octopus model. A central “brain” holds the migration's full context, coordinating six specialised “arms”, each driven by AI under FDE oversight. We have mapped that model onto an SAP ECC → S/4HANA migration in our Octopus explainer and have gone deeper to describe the architecture in our whitepaper: How to accelerate your SAP S/4HANA technical migration.
The empirical record on conventional SAP migrations is poor. Horváth's 2025 survey of 200 SAP user companies found only 8% finished on schedule, with budget overruns in over six in ten cases. This data illustrates a problem in coordination, with a lack of visibility between different teams leading to cumulative errors and weeks-long diagnostic loops. While AI assistants can accelerate the individual stages of this broken process, they can’t fix it without a central context layer being in place.
A migration operating system, built around an ontology, sits across the whole programme rather than alongside it. Validation runs continuously, with lineage becoming automatic rather than being reconstructed, and SMEs participate live rather than through tickets.
And the substrate that gets you to S/4HANA is the same one that runs the company afterwards. Post-SAP migration, the Palantir ontology gives you a single semantic layer over what was previously locked inside SAP's rigid table structures, meaning that processes, decisions, and AI agents can operate on real business objects (customers, orders, shipments) rather than cryptic table joins. The upshot is that workflows, analytics, and automation built on top stay stable even as the underlying SAP modules evolve or get swapped out, turning your ERP from a system of record into a foundation for operational decision-making.
What to take away
The SAP story is stronger than it was a year ago. The Business AI Platform consolidation is overdue housekeeping, Joule Studio 2.0 is highly valuable, and the vision for the Autonomous Enterprise and SAP Autonomous Suite is much sharper.
The deeper shift, though, is happening at the architectural level. Software across the industry is converging, with ontology as the critical engine and FDEs as the delivery vehicle. The missing piece – the migration operating system layer – is still mostly seen as someone else’s job. Palantir’s Foundry already does this work in production at scale, and SAP is now clearly moving in the same direction, even if the ontology is not yet the explicit centre of gravity.
That is good news for customers. Over the next three years, as the 2027 S/4HANA mainstream maintenance deadline forces decisions, more than one serious option will exist for where your ontology and migration operating system live. Palantir is ahead of the game today, and platforms like SAP’s will follow suit, giving CIOs a genuine choice of stack rather than a single default. The call should be made deliberately, with the next decade of the enterprise in mind, not just the next migration.
