AI Capability Doesn't Always Arrive as Features

Roughly twenty-five years ago we wrote a research note at Gartner predicting which SAP version would become a vintage release. The one customers would land on and stay on, long past the point where newer options existed, because the shape of what they had built fit them well enough and moving cost more than staying.

Forecasting that was ordinary work. Everyone could see the gap between what a vendor had shipped and what customers were actually running, and the interesting question was only where it would settle.

It settled about where you would expect. Gartner's tracking has 39 percent of 35,000 SAP ECC customers having started the move to S/4HANA by the end of 2024, on a product first shipped in 2015. Projections put roughly 17,000 still on the legacy platform in 2027 and 13,000 in 2030.

That gap is the oldest thing in enterprise software. It has not been a scandal and it is not one now.

What has changed is what piles up on the other side of it. That pile used to be countable. Somebody could work through the release notes and name what was missing, which is why the usual remedies are discovery, training, and better onboarding. Part of what accumulates now is not made of items, and no list reaches it. That is the new problem in AI capability, and it is not a problem of discovery.

The Clay

Why implementation sets what an organization believes it can do

I have always described implementation as taking a lump of clay and shaping it to the organization. The clay is the product as it ships. The shaping is every configuration decision, every process the software gets bent around, every capability switched on and every one left alone. All of it against what the product could do in the year the project ran.

The shaping was never one person's work. Clients who knew their business, consultants who knew the product and how to configure it, in a room together deciding what this thing would be here. Everything built around that, the testing, the change management, the benefits case, assumed the same thing we did: that what we were deciding about could be described.

Then the organization lives with the shape, and the shape becomes normal.

On a long enough project the question always arrived. Do we take the new release before go live. Taking it meant rework and schedule risk, and it bought time before you fell behind. Not taking it meant going live already a version back on day one, with the shape set against something the vendor had superseded while you were still building.

That conversation happened on every project long enough to need it, and it had an answer, because you could read the release notes and price the delta.

The implementation does not just deploy software. It sets the internal known. What the system does becomes what people believe the system can do, and that belief outlasts every release note that follows. Features arrive in later versions. Almost nobody in the business goes looking for them, and almost nobody in IT raises them, because raising one means proposing a project.

When I ran business applications, the processes had been built when the clay was molded, and that was what the organization knew. After a while that is simply normal. Any change is change, and I do not recall a new version ever arriving as relief.

That is worth sitting next to the entitlement argument, because it cuts against the easy version of it. Unused capability is not a gift going unopened. From the seat that has to run the place, it is work somebody is proposing.

That is the adoption clock, and it has always been the slow one. It moves when somebody decides a capability is worth the disruption and finds budget for it, or when an external deadline forces a change regardless of appetite.

End of mainstream maintenance is that deadline. A date the vendor publishes and the customer cannot argue with, which brings the clay back onto the table whether or not anybody wanted it there.

The Gates Are Working

What the vendors actually built, and why it produces the gap rather than preventing it

The reflexive story about AI in enterprise software is that it arrives unbidden and ungoverned. In core systems of record, that is mostly not what the documentation says.

Start with what changed underneath. On premise, the customer held the hardest gate that has ever existed in this industry. They held the bits. A vendor could ship anything and none of it arrived until somebody chose to install it, which is how an organization sits on one release for a decade. Version control and feature control were the same control, exercised by the same party, at the same moment.

Cloud native splits them. The code baseline arrives whether anybody wants it or not, and what remains to the customer is the switch rather than the version. That is why the gap changed shape. On premise, being behind meant running old code. Now an organization can be running entirely current code and be just as far behind, because the distance moved into activation.

• Oracle ships mandatory quarterly updates that no customer can skip, and pairs them with an Opt-In console for choosing which new features to enable and when. Oracle's own framing is that customers are in control over when, and in many cases if, they accept changes that affect business users.

• SAP gates harder still. Joule Base entitlement comes with eligible cloud subscriptions at no additional license cost, and turning it on is a project rather than a switch: platform entitlement, accepting AI terms, identity configuration, and role assignment across more than one system.

• Microsoft's Dynamics 365 finance and operations apps put Copilot behind Feature management, where the features remain enabled by default and the Copilot app is installed by default in the admin center. That is a gate that is open when it arrives.

  
  

Three vendors, three postures, and in the two that gate hardest the capability is already paid for. Oracle includes more than fifty prebuilt AI agents in the base subscription at no additional cost. SAP includes Joule Base with the subscription.

So the entitlement arrives, the gate stands where it always stood, and passing it requires a deliberate project that nothing on the calendar forces.

And there is a second thing the vendor now holds. In a cloud-native system of record the vendor operates the entire stack, which includes the model behind the application. They choose which one sits there, when it changes, whether it is pinned, how requests get routed between models, and what the customer is told about any of it.

Microsoft's documentation is only able to promise that model updates require no customer action because Microsoft controls both ends of that arrangement.

Which leaves the two decisions in different hands. The customer controls whether a feature is switched on. The vendor controls what that feature is capable of, independently of the application release. On premise those were one decision made by one party. They are now two decisions, held separately, moving at different speeds.

Which is the old gap with the purchase decision taken out of it. You are entitled to the capability. You are not running it. The distance between those two is the same distance a vintage release always measured, and closing it still costs a project.

So the question is the one implementation teams have always asked at that point. Is the juice worth the squeeze.

You price the work of activating against the value of what you would get, and you need both numbers to do it.

Producing the value number has become hard in two separate ways. Part of it cannot be seen, and the part that can be seen will not sit still long enough to be priced.

What Accumulates Is No Longer a List

The break: available capability stopped being enumerable

What piled up on the available side used to be a finite set. Features arrived as items. Each one was discrete, documented, and either taken or not. A customer three releases behind could in principle work through the release notes and count what they were missing. The gap was wide and it was countable.

Part of what accumulates now cannot be counted at all.

Microsoft documents this about its own products with unusual directness. It regularly enhances the underlying models powering Copilot, which brings performance improvements, more advanced reasoning, and expanded capabilities. Customers do not need to make changes to their environment. Existing controls, settings, and configurations are unaffected, and no new administrative action is required. And model updates are explicitly not product feature changes, which travel separately through standard roadmap channels.

Not all of that is the same thing. Performance improvements make the same feature cheaper or faster, and vendors have shipped those forever. Nobody ever needed a gate for a faster response. The reasoning is different. That moves the ceiling on what the feature can do, and it arrives on the same release train, under the same notice, with the same instruction that no administrative action is required.

Read that documentation as an operations note and it is reassuring. Read it as a governance statement and it says something harder: the ceiling on what an already-implemented feature can do moved, nothing appeared in a feature list, and nobody had to do anything.

That is not a gate being bypassed. The gate governs features and this is not one.

So the available side accumulates through two different mechanisms, not just at two different speeds.

Declared capability. The vendor says here is a new feature. This is the path every gate was built for and it still works.

Latent capability. The vendor says the thing you already have can now do more. There is governance around this on the vendor side, and there is real engineering discipline behind it. What there is not is a feature for the customer's gate to hold, because the gate was built to admit or refuse discrete things and this is not one. It is a change in what a system can do with no decision attached to it, arriving from the vendor rather than from a deployment.

Which leaves the organization in two positions at once. Features it owns and is not running, which can still be counted. And features it is running that do more than they did at implementation, which cannot. The first is a gap you could close. The second is already inside the process, doing work nobody scoped.

And the number will not hold still while you evaluate it. That was always true, which is why the go-live question existed at all. What is different is the interval. A vendor release could be seen coming quarters out, and the delta it carried was fixed once it shipped. The capability underneath moves several times inside the length of the project you would run to capture it, so the value you priced at the start is not the value you are capturing at the end, in either direction.

Which is the harder half of the juice question. It is not only that part of the value cannot be counted. It is that the part you can count is being restated while you are doing the counting.

It also breaks what the go-live conversation used to accomplish. The meeting still happens. The tradeoff worked because both sides were countable: take the release and price the rework, skip it and price the delta you start behind on. Only one of those numbers is still available.

You cannot write a test case against a capability that does not exist yet. That is not a gap in anyone's method. It is what the methods were for.

The Adoption Clock Did Not Change

Why the same slow process now produces a much larger gap

Nothing about how organizations adopt has sped up.

McKinsey's 2025 State of AI survey found 23 percent of respondents reporting a scaled agentic system somewhere in the enterprise, with no individual business function exceeding 10 percent reporting scaled use. That is the adoption clock ticking at roughly the speed it has always ticked, against entitlement that is already paid for.

I lost count of the number of times we demonstrated current features to a long-time customer and watched the surprise on their faces that any of it existed. Not new customers. People who had run the product for years, who used it every day, who would have told you before the meeting that they knew what it did.

Their clay was set too. The features had shipped, the release notes had gone out, the entitlement was current, and the internal known had not moved since the project.

That was before any of this. The gap between what a customer owned and what a customer knew they owned is not an AI problem and never was. What AI adds is a second layer to it, arriving underneath features they already have, which will not show up in a demonstration as a new thing at all.

A path exists outside the system of record entirely, where employees bring their own tools. Verizon's 2026 Data Breach Investigations Report puts 45 percent of employees as regular AI users on corporate devices, with shadow AI detections up fourfold in a year. That is a governance problem and a real one, and it is somebody else's argument.

Same slow clock. Much faster accumulation. The gap is not widening because anyone got worse at adoption.

What Actually Went Missing

The version horizon still exists and stopped doing the job it used to do

It would be too much to say the version horizon is gone. A customer can still say they are upgrading next year, and that is a real date with real force.

What weakened is its governance significance.

An organization used to be able to assume that the next major upgrade was the moment to reconsider its technological position. That assumption is what made the upgrade cycle load-bearing for far more than software. It was the scheduled re-look, the moment the clay came back onto the table.

Now the capabilities available to that organization have changed many times between one upgrade and the next, and some of those changes never appeared in a release note at all. The date still arrives. It no longer catches what it used to catch.

Which is why one sentence has quietly stopped carrying the information it used to carry.

We're on ECC 6.0.

That once told you a great deal about what an organization could do. It still tells you which features are available and roughly when the shape was set. It no longer tells you what the system is capable of.

Manufacture the Trigger

What replaces a deadline nobody has to schedule

The instinct is to ask for better notice from vendors. The notice is already there. Oracle publishes readiness materials every quarter, SAP documents activation, Microsoft posts model changes to a blog and to its message center. More notice into an admin queue does not move the adoption clock, because the adoption clock was never waiting for information.

It was waiting for a deadline it did not choose.

• Put a date on the shape. The clay was formed against what was possible in the year of implementation, and that year is the shortest-lived assumption in the entire system. It is written down nowhere. Record it, and schedule the re-look, because the maintenance calendar no longer schedules it for you.

• Ask what the shape would be today. Not whether the workflow still works, because it does. Given what the underlying system can now do that it could not when somebody drew this boundary, is this the boundary a competent team would draw now.

• Count the entitlement you are not using. For most organizations the AI capability already paid for exceeds the AI capability in production by a wide margin, and nobody holds both numbers. The gap between them is money already spent.

• Borrow the attestation. Systems subject to an attestation of control get looked at on a schedule, because somebody has to sign that they know what the system does. That is a manufactured deadline, it works, and there is no rule saying it only applies where a regulator requires it.

The Vintage Question

What a version number still answers, and what it stopped answering

The old world was slower and more expensive and it stranded organizations on software that had stopped improving. Nobody wants it back.

But it was legible. The gap between available and implemented had a name, a number, and a date, and everyone in the market understood how to read it. That is why forecasting a vintage release was ordinary analysis rather than clever analysis.

Adoption was always the slow part. Capability was not always this hard to count.

The vendors did not break that. They are still gating, still publishing, still giving customers the choice they always had. What changed is that the answer to what an organization can do stopped being fully expressible as a list of features it has turned on.

The version number still tells you what you have. It stopped telling you everything you can do.

There are four seats in the name. The fifth one is yours.