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.

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 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.

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 leverage. 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.