AMS Revenue Will Change

In the first part of this series I argued that the best strategy in SAP application management (AMS) is to destroy the demand for tickets, not to close them faster. The second order consequence would then be: if providers are good at that, don't they put themselves out of business? They don't, because the tickets that are reduced in volume and price were never the whole demand.

SAP currently manufactures the S/4 migration wave on a deadline, growing customers generate new requirements, and Brussels keeps legislating, and none of that stops. The analysts still see the AMS market growing from about $14 billion in 2026 to $25 billion by 2035. Compare that number against Part 1's ticket economics and, taken literally, I think it is wrong: the layer carrying roughly half of today's revenue is collapsing in volume and price at once, so the rest of the book would have to triple in nine years to make the forecast true.

Two channels can still grow the number: SAP widening its perimeter itself, and the falling price pulling in-house operations into the market. The work is not disappearing; it is changing shape.

Customers run out of the cheap requirements, not the requirements

The fear that customers "runs out of work" confuses the cheap work with all the work. At a fixed perimeter, with the self-improvement loop from Part 1 running, the break/fix queue does drain toward zero, and that draining is the tell that the queue was rent on instability you could have engineered out. But a SAP estate at a real company is never frozen. What is left is three other kinds of work that were always there, hidden underneath the ticket volume.

Three businesses hiding in the queue

The three are not new businesses. Providers run migrations, build change requests, and deliver compliance work today. AI does not invent them; it strips away the break/fix layer that hid how different they are from each other. Partition the demand by who drives it (the customer, SAP, and the state) and almost everything lands cleanly.

Vendor-forced demand is the one SAP manufactures for you. ECC mainstream maintenance ends with 2027, by SAP's own maintenance commitment, and Gartner counts more than 60% of worldwide ECC customers as not yet licensed for S/4HANA, so a wall of deadline-bound, non-optional migration sits in front of nearly every SAP shop in the Mittelstand. SAP's clean-core push, which keeps customers out of the core and on side-by-side extensions, drains break/fix by fiat at the same time: fewer modifications, fewer defects. SAP is running your self-improvement loop for you. And SAP grows the perimeter it forces you across. In May 2026 it completed the acquisition of Reltio, a master-data platform whose whole pitch is making SAP and non-SAP data AI-ready, and took a stake in n8n to embed workflow automation in Joule Studio. Every bolt-on widens what counts as "SAP". Wallet share is a demand instrument, and it is the first of the only two ways the market forecast can come true.

Business expansion is the bucket that scales with customers. A company that grows, acquires, enters a market, or rewires a process generates new requirements; a static one generates almost none. Steady-state AMS revenue therefore tracks the customer's rate of change, not the size of its SAP footprint. Providers are paid for the customer's dynamism, and that is a different business from being paid to keep the lights on.

Regulatory demand is the one that looks like a service and is really a product. A rule like ViDA, which mandates structured e-invoicing and near-real-time digital reporting for cross-border business transactions from 1 July 2030, lands on every SAP customer in scope at the same time and in the same form. Build the solution once and deploy it across the portfolio. A provider who does it bespoke for each client is throwing the margin away. Optimization inside the existing perimeter, the performance and cost and tech-debt work, is customer-driven and converges to done, so it sits with break/fix on the destructible side.

The corpus is created during the project, not at run

Which of the three takes priority with a particular customer is decided at the S/4 migration or in the projects, not at the AMS contract. The asset that decides everything is the corpus: the legible model of the estate, the specs, the documentation, the configuration logic, the tests, the record of why the system is wired the way it is. That corpus is rarely created during the run part; the self-improvement loop from Part 1 only adds to it. It is created during the project, by whoever does the implementation or the migration, as a by-product of the work.

And historically it evaporated at the handoff from project to run, thrown over the wall half-documented, which is precisely why break/fix existed in the first place. Nobody wrote down how the thing actually worked, so it broke, and someone got a ticket. The reflex is old and documented: Repenning and Sterman watched it kill a firm's reusable engineering library in 2001, where an engineer who skipped documenting her steps finished her own project sooner and the shared bookshelf never filled. Skipping the write-down was always individually rational and collectively ruinous. AI changes that: The project provider can now retain the corpus and turn it into the loop that runs the estate.

That change reorders the value chain. The provider who did the migration captures the agentic AMS almost for free, because it already holds the asset, while an AMS-only rival has to reverse-engineer the estate before it can even start. Implementation and run, pulled apart by two decades of multi-vendor sourcing, re-bundle around whoever owns the corpus. And the offshore AMS shop, the one whose whole model was renting cheap labor to serve a queue, is the loser, because it owns the labor that is commoditizing and not the corpus that now matters. The venture investors backing "services-as-software" have reached the same place from the other end: their advice to founders is that the model itself is commoditized, and that the durable advantage is now in how you integrate, embed, and operate.

That reframes the S/4HANA migration wave into something other than a project-revenue event. It is a corpus land-grab. The real prize is not the migration fee; it is the corpus the migration produces, which creates the AMS annuity for the next decade to whoever walks away holding it. Switching-cost economics says competition for a locked-in annuity happens upfront, and my read is that migration bids will start landing below cost because of it.

The suspiciously cheap migration bid is not generosity; it is the price of your deed. If you are the customer, the implication is precise but uncomfortable: the moment to fight for ownership of that corpus is in the implementation statement of work, before the run contract is even thought of. Claim it late and you have already given it away. I am careful with that "almost": retaining the corpus is real work, engineers embedded in the project, not a free side effect. But against a competitor starting from nothing, it is close.

Providers will re-segment

A customer with a frozen perimeter, the stable estate that used to be the ideal annuity, becomes a bad steady-state customer, because its well drains. What I expect providers to do is to finish the job: harden the estate, bill the hardening project, and reduce the customer management effort to the minimum necessary.

Providers will focus on "good" customers. The ones that are moving, growing, acquiring, entering markets, because that is where the requirements keep coming from. So the sales motion inverts. The instinct to land big, stable estates and milk them is backwards. Providers will want the businesses that will not sit still. And the other customer group is the one that is not a customer yet: the in-house teams whose run costs agentic delivery just undercut. Incidents are inelastic, nobody wants more of them, but outsourcing is not; when the price of run halves, in-house services that never left the building come onto the market.

European labor law of course limits this motion. "Finish the customer and redeploy the team" is a clean sentence on a slide and a much harder thing to do in Germany, where co-determination gives the works council a real say over how AI changes jobs and headcount. The Bitkom survey for 2026 shows the tension already: among the German firms using AI, 19% say they have already cut jobs because of it.

The run-only providers will reprice (like a taxi license)

The provider who refuses to move does not stay flat. Its book reprices downward. Once you have proven that break/fix is destructible, you have made the duration of that recurring revenue visible, and visible duration is what compresses a valuation multiple. A recurring book that everyone can now see has an endpoint gets priced like a depleting asset, not a going concern.

This is the Paris taxi license problem, run at the level of a whole book of business. The license held its price, around €240,000, until Uber and the VTC apps came and drove re-pricing: €170,000 three years later, by the European Commission's own count. The same logic is already being applied to IT services from the investor's chair. S&P frames the AI impact on technology services as "disruption without dislocation, yet", with the "yet" carrying all the weight, and Morningstar says it more bluntly, that AI is eroding the protection IT-services firms have relied on.

The underlying economics are not complicated. A business with high fixed cost and low marginal cost, which is what agentic delivery turns services into, sees its prices competed down toward marginal cost, unless it owns something that is not a commodity.

The question this leaves open

Everything so far was about revenue. It leaves an important question untouched. When agentic delivery drives the cost of the work down toward its floor the margin stops coming from doing the work, because the work is too cheap to carry it. It will be coming from owning the corpus.

That is a different fight, with a different winner depending on who holds the asset, and in the European case a legal lever the customer is only beginning to reach for, in the shape of the EU Data Act and its switching rights. Whether customers ends up with a partner or a new landlord is the third part of this series.

If you are scoping an S/4HANA migration, writing the AMS that follows it, or arguing about who owns the corpus when the project ends, I am glad to compare notes, on LinkedIn or by email. The third part, on who captures the margin once the work gets cheap, is next.