Why Systems Like SAP Still Will Not Die
From an a16z conversation on headless software: enterprise stickiness lives in customized business logic, not in pretty screens—and agents do not erase that overnight.
Ask why a heavy, aging enterprise system still sits at the center of global companies, and the common answer is inertia. The sharper answer from the a16z conversation is different: the hard part is not the database. It is the years of business logic wrapped around how a company actually runs.
Cars look alike. The decisions do not.
Sinofsky uses the auto industry as a picture. Ford, Toyota, and General Motors use broadly similar technology: assembly lines, workers, supply chains. What separates them is how they decide what to build, how much material to buy, which currencies to hedge, when to hire, and when to launch a new line. Much of that enterprise planning historically lives inside systems like SAP.
In that framing, rival carmakers are not mainly competing on who has the prettier screen. They are competing on which screens they watch, which customizations they built, and which operating judgments those systems encode. The software becomes part of the company’s muscle, not just a tool on a laptop.
Postgres plus APIs is not a replacement plan
Amble pushes back on a popular startup fantasy: that a modern database and a stack of APIs can rip out SAP. The valuable thing is rarely “where the rows are stored.” It is the business logic that took years to implement—not because consultants are slow for sport, but because the system has to match how the company really works. Close enough is not good enough when money, inventory, and compliance are on the line.
Scale makes the gap obvious. In a forty-person company, expense reports can be a friendly chaos: photo the receipt, auto-classify it, move on. With a hundred thousand employees across twenty countries, the same problem collides with local law, layered company policy, union rules, and tax requirements. That is the complexity enterprise software absorbs—and why “vibe coding a Salesforce clone” often underestimates the real job.
Stickiness grows into the organization
Amble’s account of stickiness is plain: software becomes hard to leave because people build habits around it—how often they read and write data, how often they enter the system, and how many undocumented norms form around those clicks. Sales lives in the CRM; finance bills from its data; marketing depends on the same upstream facts. Compliance then adds a harder layer: there must be one trusted set of numbers.
Sinofsky adds a blunt version of the same idea: once you are collecting money, stopping is hard, and deciding what happens after you stop is harder. Sticky features are often not the ones a product meeting planned as “our moat.” They are the parts that grew into shared calendars, access rules, and workflows until the organization cannot move without them.
What agents change—and what they do not
None of this means agents are useless around enterprise software. The conversation’s more useful claim is that value is shifting from merely collecting data to making data conversational and usable: natural-language queries, customized reports, cross-document analysis that used to be painful. Enterprise software often already could generate the chart you wanted. The bottleneck was knowing how—or having permission—to make it happen.
What agents do not erase overnight is the tacit operating knowledge wrapped into those systems: who approves what, which exceptions matter, how a process really runs when the happy path fails. Replacing a long-lived ERP is still less like swapping a hard drive, and more like transplanting an organization’s memory. That is why systems like SAP keep surviving waves of reinvention—and why the hard opportunity is often to work with that complexity, not pretend a clean demo has already deleted it.