Can You Run AI Agents on SAP ECC Without Moving to RISE?

If you run SAP ECC, you have probably had a version of this conversation. Someone on the leadership team asks why the company is not using AI in finance or supply chain yet. You explain that SAP's AI runs on the cloud editions. They ask when the migration finishes. You say 2027, maybe. The conversation ends, and nothing happens for another quarter.

That pattern is now visible in the data. SAP shipped more than 40 specialized AI agents and over 2,400 Joule Skills across its portfolio in the first quarter of 2026. Yet the DSAG Investment Survey 2026 found only about 3% of SAP customers run SAP Business AI in production, while roughly 77% of AI-active enterprises use non-SAP tools like Microsoft Copilot instead.

That gap is not about appetite. It is about eligibility.

Joule does not run on ECC, and that is by design

SAP Joule is available to customers with a RISE with SAP or GROW with SAP contract. On-premise installations are excluded — no Joule, no agent-to-agent protocol, regardless of budget or readiness. On-premise S/4HANA sits in an awkward middle position, requiring a BTP add-on rather than working natively.

This is not an oversight or a roadmap gap that closes next year. Joule's availability is one of SAP's strongest arguments for moving to the cloud, and with ECC 6.0 mainstream support ending on 31 December 2027, more than 10,000 customers worldwide are hearing that argument in every renewal conversation.

The commercial detail matters too. Joule is billed through SAP AI Units, and RISE contracts include a base allotment that customers frequently find insufficient at production scale. Overage runs well above the contracted rate. So even after migrating, AI is a consumption line item, not something included in the move.

None of this makes migration a bad decision. S/4HANA is where your ERP is going, and the deadline is real. The problem is the sequencing that vendors imply: migrate first, then get AI. That order costs you two to three years of value on processes that are painful right now.

The two-to-three year problem

Most ECC-to-S/4HANA programs run 18 to 36 months from business case to cutover. During that window, the argument for waiting on AI sounds reasonable — why build on a platform you are retiring?

Here is why it does not hold up.

The processes that hurt most on ECC are the same ones that will hurt on S/4HANA. Three-way match exceptions, vendor master maintenance, sales order entry, AP aging, and demand planning are not artifacts of your ERP version. They are artifacts of manual work volume, and they continue after cutover.

Meanwhile, your migration itself would benefit from cleaner master data. Data quality is one of the most common causes of S/4HANA program delays, and it is precisely the kind of high-volume, rule-bound work an agent handles well.

And the cost of waiting compounds. Two years of month-end closes running at current speed, two years of AP exceptions handled by hand, two years of planners rebuilding the same spreadsheet.

ECC is more agent-friendly than people assume

The reason "AI needs the cloud" sounds plausible is that it is true of SAP's own products, not of the technology.

ECC exposes stable, well-documented interfaces that most organizations already use: RFC and BAPI for transactional operations, IDoc for document flows, and SAP Gateway OData services where teams have built them. Many ECC landscapes already route these through PI/PO or Cloud Platform Integration.

An agent does not need a modern platform. It needs a reliable way to read your data and a permitted way to act on it. ECC provides both, and has for twenty years.

What ECC does not provide is a way to make a language model reliable against it, which is the part that actually requires engineering.

Reliability is about constraint, not model choice

Point a general-purpose model at SAP and it will improvise. It will invent field names, guess at entity paths, and produce filter syntax that looks correct and returns nothing. This is the single most common reason SAP AI pilots fail their first serious test.

The pattern that works is metadata-first. The agent reads the actual schema and available operations from the system rather than generating queries from memory, then composes calls only from what genuinely exists. Reliability comes from narrowing what the agent is allowed to do, not from a longer prompt or a larger model.

The same principle governs write-back. An agent that can post a document needs to run under a scoped service identity with the permissions you grant it, pass a human approval gate before anything commits, and log every action in a form an auditor will accept. This matters more in an ECC environment than anywhere else, because your ECC system is the system of record for a business that has been running on it for years.

That governance requirement is not a constraint we work around. It is the reason agents on ECC are viable at all.

Agents you build now move with you

This is the argument that changes the sequencing decision.

An agent connected to ECC through an integration layer is not tightly coupled to ECC. When you cut over to S/4HANA, you re-point the integration rather than rebuild the agent. The business logic, the approval rules, the escalation paths, and everything your team learned about where the agent helps and where it does not — all of that carries forward.

So the choice is not "AI now on a dying platform" versus "AI later on the right one." It is whether you spend the migration window accumulating operational value and organizational experience with agents, or spend it waiting.

The organizations that wait will start their AI learning curve on the day their S/4HANA program ends, which is exactly the moment their teams have the least capacity for something new.

Where to start on ECC

The strongest first use cases are high-volume, rule-bound, and painful enough that everyone already agrees they are a problem:

Three-way match exceptions (MIRO). Invoice, PO and goods receipt reconciliation is the most reliably automatable process in most ECC landscapes, and the one where hours disappear.

Vendor master maintenance. Rule-driven, high-volume, and directly useful as migration preparation.

Sales order entry. Especially where orders arrive by email or PDF and get keyed in by hand.

AP aging and cash visibility. Answering "what is due, to whom, and what is blocked" without building a report.

Master data cleanse. The work your S/4HANA program will require anyway, started early and run continuously.

Pick one. Run it in a sandbox against real data, not a demo dataset. Measure it against your current baseline rather than against a vendor's benchmark. If it works, the second one is far easier.

The practical question

If your migration is scheduled and funded, migrate — that is the right call regardless of AI.

But if you are still building the business case, or the program has slipped, or you are one of the organizations that will realistically be on ECC past 2027, the question is not whether you can use AI agents. You can. The question is whether you will spend the next two years finding out what they are worth to you, or waiting to begin.

Agentnomics connects directly to SAP ECC and S/4HANA through RFC, BAPI, IDoc and Gateway OData — no RISE contract, no BTP add-on. Pre-built agents for finance, HR and supply chain run against your live system with scoped permissions, approval gates and full audit logging.

Book a demo · Start a free trial