Headless used to be how you build. Now it's how you escape.

For most of the time this publication has existed, headless meant one thing: a way to build. Expose the backend as an API, treat the interface as optional, design for the machine that will operate the system instead of the human who used to. That argument is mostly won. The interesting move this month is that headless picked up a second meaning, and it points in the opposite direction. Headless ERP is becoming an escape hatch.

On June 16, 2026, one week after SAP shipped a patch that technically blocks third-party AI agents from calling its APIs, Rimini Street CEO Seth Ravin told The Register that ERP customers can use the same architecture to get out. Not to build a better agent on top of SAP. To leave the upgrade treadmill that SAP and the other database incumbents have run for thirty years.

The timing is the story. The week SAP turned its API into a gate, a third-party support vendor turned headless architecture into a door. Both are using the same fact: when a system is genuinely API-first, the front end, the agent, and eventually the database underneath all become things the customer can swap. The vendor sees a chokepoint. The customer sees a way out. Headless is the architecture both are fighting over.

What Rimini Street is actually selling

Rimini Street is not a software vendor. It sells third-party support for SAP and Oracle systems, which means its entire business is helping customers stay on software the original vendor wants them to replace. In June it extended support for all SAP ECC 6 and S/4HANA releases through 2040. That date is the thesis. It is a bet that customers want off the forced-march upgrade cycle, and that they will pay someone to help them stand still.

Headless ERP is the next step in that bet. The mechanics Ravin described are simple. Build a new interface layer on top of the existing ERP, made of AI agents and workflow software rather than the vendor’s own screens. Run the business through that layer. Then, when the business is ready, swap the pieces out one at a time. Eventually move the underlying business data off the vendor’s proprietary database to an open option like PostgreSQL or MongoDB.

Read that sequence carefully, because it inverts the usual headless argument. The headless thesis normally treats the backend as the durable asset and the UI as the disposable layer. Ravin is treating the entire vendor stack as disposable, one layer at a time, with headless as the technique that lets you replace each layer without stopping the business. The API surface is not the thing you protect. It is the seam you cut along.

The last layer in that sequence is the one that matters most, and it is the one the incumbents guard hardest. Replacing screens with agents is cosmetic if the business data still lives in a proprietary database the vendor controls, on storage the vendor licenses, in a schema the vendor can change under you. That is where lock-in actually compounds. Oracle’s database business and SAP’s HANA stack are not incidental to the application; they are the reason the application is hard to leave. Moving the data to PostgreSQL or MongoDB is the only swap that converts a captive customer into a portable one, which is precisely why Ravin’s roadmap ends there and not at a prettier UI. Everything before it is preparation for that one migration.

Ravin was blunt about why this scares the incumbents. Agentic AI, he told The Register, is “scaring the hell out of everyone from SAP on down.” The vendors, he said, “built a business off controlling a customer by having all of this software, and they tell them when to [upgrade] and what to move to.” Headless breaks that grip because it decouples the thing the customer actually runs from the thing the vendor actually sells.

What a headless ERP migration actually looks like

Ravin described the sequence in a few moves. It is worth slowing down on each, because the abstraction hides where the real work and the real risk sit.

The pattern underneath is the strangler fig, applied to an ERP instead of a monolith web app. You do not rip out SAP and stand up a replacement over a weekend. You wrap it, divert work module by module, and let the old system shrink until what remains is small enough to retire or leave in place.

Move one is the read layer. Before any agent can safely operate the ERP, the business needs a clean, queryable copy of what the ERP knows. That usually means change data capture off the vendor’s tables into a store the customer controls, so reporting, agents, and new interfaces read from a surface the vendor does not gate. This step alone breaks the reporting lock-in that keeps most ERP customers from ever looking elsewhere.

Move two is the interface and workflow layer. Agents and workflow software take over the tasks that used to run through the vendor’s screens: approvals, order entry, reconciliation, exception handling. The ERP is still the system of record, but the people and agents doing the work no longer touch it directly. They touch the layer the customer built.

Move three is the write path, and it is the hard one. Reading from a captured copy is low risk. Writing back into a live ERP through its APIs, under its validation rules, without corrupting financial state, is where most modernization projects stall. An anti-corruption layer sits here, translating between the customer’s model and the vendor’s, so the customer’s logic is not quietly reshaped by the vendor’s schema.

Move four is the core swap. Once the interface, the workflow, and the write path all run through customer-controlled layers, the underlying database becomes a dependency rather than a destiny. The business data moves to PostgreSQL, MongoDB, or another open store, and the vendor’s runtime becomes one more replaceable component.

Most customers never reach move four, and that is the point. The first three moves are what make it possible, and each one pays off on its own even if the customer never takes the last step. A migration that only rewards you at the end is a migration nobody starts. A headless ERP migration returns value at every stage: better reporting after move one, agent-run operations after move two, portable business logic after move three. The exit is the option you buy, not a bill you have to settle up front.

The escape hatch only works if the core is genuinely headless

There is a hard condition buried in this pitch, and it is the same condition this publication has been measuring all along. You can only leave through an API that exists and that you are allowed to call.

A headless ERP escape is a sequence of swaps: replace the interface, replace the workflow logic, replace the agent layer, replace the database. Every one of those swaps depends on the layer underneath exposing a clean, documented, machine-operable surface. If the data model is locked inside the vendor’s proprietary format, the final swap never happens, and the customer has merely rebuilt the front end while staying captive at the bottom. The database is where lock-in actually lives, which is exactly why Ravin’s sequence ends there and not at the UI.

This is why the architecture and the politics cannot be separated. Salesforce shipped Headless 360 and put “No Browser Required” on the screen, exposing its whole platform as API, MCP, and CLI. That move makes Salesforce more operable by agents. It also, in principle, makes a Salesforce org more portable, because everything is now reachable programmatically. Exposure cuts both ways. The same surface that lets you build an agent against a platform lets you build a migration off it.

The incumbents understand this, which is why the openness is never unconditional. SAP went the other direction in the same window, and the contrast is the entire point.

The data-ownership mechanics nobody reads until it is too late

Data ownership is the phrase every vendor now agrees with and almost none of them mean the same way. Owning your data is not a checkbox in a contract. It is a set of concrete rights and formats that either exist or do not.

Start with the distinction between having your data and being able to use it. Most ERP contracts already grant the customer the right to export their records. What they rarely grant is export in a form that is usable without the vendor’s software. A nightly dump of proprietary tables, with meaning encoded in a schema only the vendor documents, is technically your data and practically useless. The lock-in was never that you could not get the rows out. It was that the rows meant nothing without the application that wrote them.

This is why the schema, not the storage, is the real asset. An ERP’s value is in the relationships: which ledger entry ties to which order, which cost center rolls up to which entity, which state transitions are legal. SAP encodes a large part of that logic in its own data dictionary and in ABAP application code, not in the database in a portable way. Move the tables to PostgreSQL and you have the data without the meaning. Move the tables plus a modeled, documented semantic layer and you have something you can actually run a business on.

Genuine data ownership therefore has three tests, and a headless ERP strategy has to pass all of them. Can the data be exported continuously, not just once through an emergency escape hatch, so the customer’s copy is always current? Is it exported in an open, self-describing format, so table meaning travels with the data rather than living in the vendor’s documentation? And is the semantic model, the part that says what the data means, owned by the customer rather than licensed from the vendor?

The vendors that answer yes to all three are rare, which is exactly why third-party support and challenger positioning has room to exist. A vendor whose revenue depends on the upgrade cycle has no incentive to make its schema portable, because a portable schema is a customer who can leave. Data ownership, in other words, is not a feature the incumbent forgot to ship. It is the feature the incumbent’s business model is built on withholding.

The buyers already decided

The reason a 2040 support date and a database-migration roadmap are commercially viable is that the customer side has already turned against the traditional model. This is not Rimini Street talking its own book into a vacuum.

Research conducted by Censuswide, cited in the same Register reporting, found that 70 percent of CFOs, CISOs, CIOs, and CEOs do not see traditional ERP as the future. When asked what they prefer instead, 36 percent favored a “composable, modular, flexible, API-driven, best-of-breed model,” and 33 percent leaned toward “agentic ERP” with autonomous, AI-driven decision-making. Add those two and roughly seven in ten senior buyers want a system defined by APIs and agents, not by a monolithic suite and its upgrade calendar.

That is the demand headless ERP is built to meet. Constellation Research, covering Rimini Street’s pivot toward agentic AI and UX, frames the company’s second act around exactly this shift: agents and interface layers that sit on top of aging ERP cores and let customers modernize the experience without the vendor-mandated rebuild. The appetite is documented. The product is the response to it.

The connection back to the market story is direct. We argued in the SaaSpocalypse piece that per-seat pricing was an arbitrage on human labor that agents dissolve. Headless ERP is the architectural expression of the same pressure one layer down. If the system is composable and API-first, the vendor can no longer bundle the database, the application, the interface, and the upgrade cycle into a single non-negotiable contract. Each piece gets priced, and replaced, on its own.

How agentic access rewrites the ERP buy decision

For thirty years the ERP purchase was a bet on a suite. You picked a vendor, accepted its data model, its interface, and its upgrade calendar as a single package, and you optimized your business around what the suite made easy. The buying question was “which suite,” and the answer locked in a decade.

Agentic access changes the question. When the primary operator of the system is an agent rather than a trained human clicking through the vendor’s screens, the interface stops being a differentiator. An agent does not care whether the vendor’s UI is good. It cares whether the API is complete, documented, and callable without a gatekeeper. The features that used to sell ERP, the polish of the front end and the breadth of the built-in workflows, are precisely the features an agentic buyer discounts, because the buyer intends to build that layer itself.

That shifts what an ERP buyer is actually evaluating. The old scorecard weighted functionality and usability. The agentic scorecard weights three things the old one barely mentioned. How completely the system’s functionality is exposed as an API, rather than trapped behind screens. Whether that API is API-first by design or a thin wrapper bolted onto a UI-first product, because the two behave very differently under agent load. And whether the architecture is composable, so the buyer can adopt the parts it wants and replace the rest, instead of swallowing the suite whole.

A composable, API-first, agent-operable ERP is worth more to this buyer than a more capable monolith, even when the monolith does more out of the box. The reason is optionality. The composable system can absorb the buyer’s own agents and, when a better component appears, adopt it without a migration project. The monolith cannot, because its value was always bundled and its parts were never meant to come apart.

This is why agentic ERP is not just a nicer interface on the same suite. Bolting an agent onto a monolith gives you a monolith you can talk to. It does not give you a system you can leave, extend, or recompose. The buyers in the Censuswide research who split between the composable, API-driven model and the agentic model are describing two halves of one requirement: a system defined by its interfaces, not its screens, and owned at the layer that matters rather than rented as a whole.

Headless cuts both ways, and that is the real lesson

A month ago we wrote that SAP locked the API and the headless era now has gatekeepers. That piece made the case that going headless is an architectural choice, but who may drive the API is a vendor decision, and SAP had just proved it by routing all third-party agents through its own Joule layer. The corollary was that headless is necessary but not sufficient. Exposure does not equal access.

The Rimini Street move is the same coin, other face. SAP used headless architecture to build a toll booth. Rimini Street is using headless architecture to build an exit. Both are correct readings of the same property. When everything becomes an API, control concentrates wherever someone is allowed to say no, and freedom concentrates wherever the customer can still say yes. The architecture is neutral. The access policy is the whole game.

This reframes how to think about every API-first vendor pitch you will hear this year. “We are headless” is not a promise of openness. It is a statement about mechanism, not intent. The real questions sit one level below the architecture diagram. Can a third-party agent call this surface without routing through the vendor’s runtime? Can the underlying data be exported in an open format the customer can host elsewhere? Are those rights contractual, or are they revocable in the next policy patch? SAP answered no, no, and revocable. The headless ERP pitch is a bet that enough customers want a vendor who answers yes.

What this means for how you build and buy

For enterprise architects, the headless ERP moment turns a question of design into a question of control. The point of going API-first is no longer only that agents can operate the system. It is that you, not the vendor, decide which agents, which interfaces, and eventually which database the system runs on.

That changes the order of operations. The most durable asset in an agentic enterprise is not the application and not the agent. It is the data, in a format you control. Ravin’s sequence ends at PostgreSQL or MongoDB for a reason: the migration is only real once the data is somewhere the original vendor cannot fence. Architects who want the option to leave should treat the open data layer as the first investment, not the last, and treat the vendor’s application as a replaceable tenant on top of it.

For vendors, the strategic fork is now explicit and public. One path is SAP’s: expose the platform, then meter and gate who may consume it, and defend margin through control of the agent path. The other is the one third-party support and challenger vendors are betting against the incumbents: expose the platform and compete on being the easiest system to operate and the easiest to leave, on the theory that the vendor who is safest to adopt wins the agentic-era buyer. Both can work. They can’t both be claimed at once, and buyers are getting better at telling them apart.

The two strategies diverge on three questions that no architecture diagram answers on its own.

A vendor that answers “no, constrained, revocable” is optimizing for capture. A vendor that answers “yes, yes, yes” is optimizing for adoption. The Censuswide numbers say the second column is where the buyers are heading.

For the rest of us tracking this shift, the headless ERP story closes a loop. Machine consumability, the property The Headless Index was built to score, was always pitched as a measure of how well agents can operate a system. The escape-hatch framing shows it is also a measure of how easily a customer can walk. A genuinely headless system is a portable one. A vendor that gates its API is, by the same logic, raising its own exit cost on purpose.

The architecture was never the question

The first phase of the agentic shift settled whether software would become machine-operable. It has. SAP, Salesforce, Oracle, and the rest have all conceded the point, some by building toll booths on top of it. The headless ERP moment opens the second phase, and the second phase is about direction. The same API surface that lets an agent in lets a customer out. Vendors are now choosing, in public, which of those two properties they want to optimize for.

Seth Ravin’s bet is that a meaningful share of enterprises, having watched SAP turn an architecture into a leash, will pay to keep the architecture and drop the leash. The buyer research suggests he is not early. Seventy percent of senior decision-makers already say the monolith is not the future. The only open question is whether the incumbents respond by opening up or by gating harder, and the SAP patch from June 9 is not an encouraging sign.

Headless was the architecture. Whether it becomes a gate or a door is the decision that actually matters now, and for the first time the customer has a credible way to force the answer.

If you are mapping these shifts as they happen, the related reading on SAP’s API lockdown and the SaaSpocalypse correction traces the two halves of the same pressure, and the newsletter follows the next moves as vendors pick a side.