The standard ERP support contract is engineered to make sure your run-rate goes one direction. Up. Forever. By design.

That isn’t a flaw in any single vendor’s offering. It’s the structural design of the entire category — fixed monthly fees, annual escalators, multi-year auto-renews, bundled cloud markup. Whether your platform gets healthier or sicker, whether your tickets get root-cause closed or just deflected, whether you need the vendor next year or not — the bill goes one direction.

A $1M ERP support contract signed in 2010 is a $1.7M contract in 2026 at a modest 4% annual escalator. At 6%, it’s $2.4M. And in both cases, the actual workload has likely shrunk: cloud migrations have moved capacity off-premise, automation has retired entire categories of routine tickets, and modern ERP platforms throw fewer errors than the ones they replaced.

The vendor is being paid significantly more in 2026 than in 2010 to support significantly less work.

This is not an accident. It’s the contract.

“The vendor is being paid significantly more in 2026 than in 2010 to support significantly less work.”

I Why it stayed broken

The inflationary ERP support contract worked for two decades for one reason: nobody was checking the math.

In 2008, ERP labor was abundant and relatively cheap. A 5% annual escalator on a $1M support contract was $50K — a rounding error against ERP project budgets that ran tens of millions. CFOs accepted IT inflation as the cost of running a global business. CIOs accepted it because the alternative was rebuilding the support team in-house, which was harder and riskier than absorbing the price increase.

Meanwhile, vendors got dramatically more efficient at delivery. Offshoring moved cost structures down. Automation retired entire categories of routine work. RPA and runbook orchestration freed senior engineers to handle multiple customers in parallel. By 2020, the cost of delivering an hour of ERP support was a fraction of what it had been a decade earlier.

None of those efficiency gains went to the customer.

“None of those efficiency gains went to the customer.”

There is a structural reason the category could hide this for two decades. In the typical enterprise, the overwhelming majority of the technology budget is spent simply keeping existing systems running. McKinsey’s budget research puts the “run” layer at roughly 85% of IT spend in lean-operator organizations, against barely 13% for change¹ — and it estimates that technical debt alone accounts for around 40% of the entire IT balance sheet. When five of every six dollars are committed to keeping the lights on, no one has the time, or the mandate, to audit any single line inside that 85%. ERP support sat there, compounding quietly, decade after decade.

The vendor’s revenue per customer kept compounding upward. The vendor’s cost per customer kept compounding downward. The gap — which used to be the firm’s normal operating margin — became something else: structural rent extraction on customers who had no leverage to renegotiate.

That math went unchecked for a long time because nobody had a reason to check it. The board wasn’t asking about ERP support line items. The CFO was looking at the IT budget as a whole, not at any single contract. The CIO was busy with transformation projects, not Run-layer cost engineering. ERP support became one of the safest line items in the enterprise — predictable, ignorable, and silently compounding.

In 2026, three things are changing simultaneously.

II Why it can’t stay broken

First: SAP ECC mainstream support ends in 2027.² Every ECC customer faces a forced decision — migrate to S/4HANA, pay extended-support premiums, or move to a third-party support provider. All three options expand the support line item at the moment a customer can least absorb it.

Second: the labor pool that supports legacy ERP is contracting. Oracle’s Lifetime Support Policy commits Premier Support for JD Edwards EnterpriseOne 9.2 through at least 2037,³ but the engineers who actually run JDE installations are aging out of the workforce faster than the platform’s official lifecycle. By 2030, the cost of qualified JDE labor will be set by scarcity, not by competition. Any contract structured with a generic annual escalator will look quaint against the actual market for the labor.

Third — and this is the one boards are now asking about directly — the AI cost pressure on IT budgets is not theoretical. Every Fortune 1000 board has asked its IT leadership a version of the same question in 2026: How are you funding our AI investment without adding headcount? The honest answer, in most enterprises, is that AI initiatives are being funded by squeezing other line items. ERP support is the largest, most stable, most squeezable line item in most enterprise IT budgets.

This is not a soft trend. Gartner projects worldwide IT spending past $6 trillion in 2026, growing in the low teens — but a large share of that growth is not expansion, it is reallocation: enterprises cutting low-ROI software and trimming contractors to fund AI, while close to a tenth of the IT budget is consumed just absorbing vendors’ price increases on software they already own.⁴ In that environment, a support line that compounds upward while its workload falls stops being an ignorable line. It becomes the first place a disciplined CFO looks.

A CIO in 2026 has three choices.

1. She can negotiate her existing fixed-fee contract down by a few percentage points and hope that buys her enough budget headroom. It will not. The escalators catch up within a year.
2. She can rebuild her ERP support team in-house. This worked in 2010. It does not work now — the labor isn’t there, the AI projects are competing for the same engineers, and the rebuild takes three years she doesn’t have.
3. Or she can change the contract structure entirely. Move from a fixed fee that compounds up to a recalibrated fee that bends down. Tie the vendor’s revenue to actual workload, not to a procurement template signed in 2018.

The first two options preserve the status quo. The third is the only one that creates compounding budget capacity for the AI decade ahead.

III The market sells two kinds of support. Neither bends the curve.

When a CIO goes to market for ERP support, the offers fall into two families. Both are run by competent firms. Neither is structured to make your run-rate fall — and once you see why, you stop expecting it to.

The product-support model — keep the software alive. This is the software vendor’s own maintenance line — SAP, Oracle — and the third-party support firms that undercut it, Rimini Street and Spinnaker among them. What you buy is the platform’s continuity: break-fix, patches, security fixes, and tax, legal, and regulatory updates.⁵ Third-party support does this genuinely well, often at half the vendor’s maintenance fee. But look at the boundary of the scope. It is the product, not your operation. These providers keep the software supported; they have neither the mandate nor the mechanism to go into your environment and retire the recurring tickets your business actually generates — the integration that breaks every period close, the batch job that fails every Sunday night, the custom object that throws the same error every quarter. And because the fee is anchored to your license base or a flat maintenance percentage, it does not move when your real workload falls. Third-party support lowers the altitude of the bill once. Then it holds flat. It never bends the curve.

The systems-integrator model — staff the work, sell the next project. This is the global SIs and application-managed-services firms: Accenture, TCS, Infosys, Capgemini, Deloitte, and their peers. Here you are buying people and hours, and the work gets done — often well. But the pricing tells you where the incentive sits. Where the engagement is time-and-materials or staff augmentation — still the most common structure for ERP application work⁴ — efficiency is the vendor’s loss, not your gain: every ticket automated away is a billed hour subtracted from the invoice. A relationship paid by effort has no reason to engineer the effort down.

And the support contract is rarely the prize. It is the wedge. The managed-services relationship is the land; the expand is the migration, the S/4HANA program, the “transformation” — the next statement of work, pitched while the Run layer it was supposed to stabilize is still on fire. The CIO who wanted the firefighting to stop gets a roadmap deck and a fresh SOW instead, and a core team asked to absorb a transformation it has no capacity to run.

Both models are coherent businesses. Neither is built to do the one thing the math now requires: take the work your platform generates, make less of it every month, and let your bill fall with it. Product support holds the line flat. Effort-priced services grow with the effort. Of the three structures a CIO can actually buy in 2026, only one has revenue that is engineered to shrink.

“Product support holds the bill flat. Effort-priced services grow with the effort. Only a deflationary contract is built to shrink.”

IV Fixed-fee ERP support is an insurance policy

Here is what fixed-fee ERP support actually is, stripped of the procurement language: an insurance policy.

You pay a fixed monthly premium structured to cover worst-case workload. Peak ticket months, environment crises, integration emergencies. The vendor calculates the premium against the spike — the moment when they might need to staff up — not against the median month or the quiet month. The premium is the spike’s cost amortized across every month of the year.

Whatever happens to your actual consumption, the premium is the same.

• AI accelerates throughput, retiring 40% of recurring tickets? The vendor pockets the gain. Premium unchanged.
• Platform matures and ticket volume drops? Vendor keeps it. Premium unchanged.
• Quiet month — your team’s busy with other priorities and the queue stays light? Same.
• Workload halved over three years as root causes get closed and automation takes hold? Premium unchanged.

A big portion of what you pay every month is buffer. Margin held in reserve for the scenario where things spike. You pay the buffer every month whether the spike comes or not.

By year three of a flat-fee contract, you have paid 36 monthly insurance premiums on a platform that almost certainly needed dramatically less attention than year-one numbers anticipated.

Allari’s contract is structured the other way. We charge for the work the team actually did, on a consumption basis. Each month we sit down with you, walk through the work, and queue the next automation or root-cause project together. No insurance premium. No capacity reservation fee. Workload halves, spend halves. AI retires recurring tickets, the spend retires with them. Quiet month, light spend. You consume what you consume.

It is the same model your cloud bill works on. AWS doesn’t charge you for the EC2 capacity you might use during a spike — it charges you for the compute you actually consumed. ERP support should work the same way.

V What a deflationary contract actually has in it

A deflationary ERP support contract has four structural features. None of them are radical individually. All four together are nearly absent from the existing enterprise market.

• No multi-year term commitment. The customer is not locked into a multi-year contract. There is no five-year envelope to protect the vendor through one full compression cycle. The customer stays because the work is compressing — not because the contract makes leaving expensive.
• Consumption pricing, reviewed monthly with the customer. The customer pays for the work the team actually did. Each month, customer and vendor sit down together, walk through the work in OpenBook®, and queue the next automation or root-cause project. The customer’s IT team is reading the same ledger the vendor uses. There is no negotiation theater — the number is the math.
• At-will termination, no penalty. If the contract isn’t working, the customer says stop and we stop. Same day. No notice period, no clawbacks, no transition fees, no contractual punishment for the customer deciding the relationship has run its course. The vendor hands over documentation, runbooks, and active ticket history on the way out.
• Continued work earned every month, not assumed. The customer doesn’t renew at a renewal date — the customer keeps the relationship going each month because the monthly review shows the work is compressing. If run-rate stops bending, the customer leaves. The vendor’s continued revenue is tied to compression performance every month, not to procurement inertia at the end of a multi-year term.

Each of these features individually exists in some niche corner of the services market. Combined, they describe a contract and delivery model that almost no enterprise has been offered. It is deflationary because every feature is engineered to make the cost bend down — by giving the customer leverage every month, by tying the price to the work actually done, and by making the vendor’s continued revenue dependent on compression performance, not on procurement inertia.

VI The math, in plain language

A fixed-fee contract with a 5% annual escalator looks like this over three years:

• Year 1: $1.00 (baseline)
• Year 2: $1.05
• Year 3: $1.10

Total over three years: $3.15. The vendor’s revenue is +10.25% from baseline. The customer’s run-rate is +10.25% from baseline. Whether the workload changed is irrelevant.

A deflationary contract — same baseline, with monthly consumption pricing against the work the team actually did — looks like this:

• Year 1: ~$0.92 — typical compression 8% as initial root causes are eliminated
• Year 2: ~$0.78 — consumption declines as backlog clears
• Year 3: ~$0.69 — compression compounds as root causes accumulate and AI tooling matures

Illustrative TCO curves over a three-year engagement. Methodology available on request.

Total over three years: $2.39. The customer’s run-rate is approximately 30% below baseline by year three. The vendor’s revenue per customer compresses by roughly the same margin — and that is the point. See this on a live engagement →.

A vendor compensated this way has only one path to growing total revenue: signing more customers. The customers it already has cannot be compounding revenue sources. They must be compressing revenue sources, by contract.

That is the deflationary thesis. The contract is structured so the vendor’s economic interest is aligned with the customer’s economic interest, not against it.

VII The evidence

Allari has been operating deflationary contracts for over a decade. Across customers including Global electronics manufacturer, Global advanced-materials manufacturer, National services leader, Global hand-tool manufacturer, and Global agricultural distributor, the pattern is repeatable.

At Global electronics manufacturer, chronic backlog — the percentage of tickets aging beyond ten days — compressed from ~12% at the March-2024 engagement baseline to ~6% by mid-2025.⁶ A 50% reduction, measured across the 463-ticket January–February 2025 sample window. Average ticket closure: 1.77 days (−72% from 6.42). Zero reopened tickets in the same window.

These are operational outcomes, but they map directly to financial outcomes: fewer recurring tickets means less consumption, which means the monthly statement compresses on its own. The 36-month longitudinal study at Global electronics manufacturer produced a Year-1 cost compression of approximately 19% against the prior Run budget baseline, held at 81% of budgeted across the first 14 months.

The pattern is not unique to Global electronics manufacturer. Across the engagement portfolio:

• Year 1 typically compresses run-rate by 8% against baseline.
• Year 2 compounds to approximately 22% below baseline.
• Year 3 lands at approximately 30% below baseline.

These are not asymptotic curves. Year 4 compresses further than year 3, year 5 further than year 4, until the engagement reaches steady state — typically around 50% below the original baseline, sustained.

Methodology is available on request.

VIII The decade ahead

If the deflationary thesis holds — and the evidence to date suggests it does — the enterprise ERP support category is going to bifurcate over the next ten years.

The CIOs who restructure their contracts now will spend the next decade with compounding budget capacity. By 2030, their ERP support line item will be 40–50% below where it is today. The savings will fund AI investment, modernization, talent retention, and the next round of platform transitions. The IT function will be a source of capacity for the rest of the business, not a sink for it.

The CIOs who don’t restructure will spend the next decade fighting the math. Their ECC 2027 migration will be expensive. Their JDE labor costs will rise faster than general wage inflation as the labor pool contracts. Their board will keep asking why AI investment isn’t accelerating, and the honest answer will be that the ERP support line item is eating the budget. Some will scramble to compress mid-decade and lose the compounding effect. Some will accept the inflation as a cost of doing business and explain to the board, year over year, why IT productivity isn’t improving.

“The deflationary contract isn’t a philosophy. It is the only structure where the math works between now and the end of the decade.”

The category is being rewritten. The contracts being signed in 2026 and 2027 are the ones that will determine which side of the bifurcation a given company sits on through 2035.

The deflationary contract isn’t a philosophy. It is the only structure where the math works between now and the end of the decade.

This is the thesis Allari was built to prove. The next decade will measure whether we were right.