AI for SAP ECC: The 2026 Guide — Without RISE, BTP or Migration
Thousands of companies still run SAP ECC 6.0. Their systems are stable, deeply customized, and business-critical — and until very recently, SAP’s answer to “when do we get AI?” was simple: migrate first. This guide covers what actually changed at Sapphire 2026, what SAP’s conditions for AI on ECC really mean in practice, and how to run AI against your ECC or on-premise S/4HANA system today, with nothing but an ABAP transport.
Written by the team behind ABAPilot and drawing on 17+ years of ECC, CRM/BRIM and S/4HANA delivery. A version of this argument first appeared in E3 Magazine.
Why there’s an AI gap on ECC at all
Almost every AI capability SAP ships is built on an assumption: a clean-core, cloud-connected landscape. Joule, Joule Agents, the Generative AI Hub, the official ABAP development tooling — all of it presumes S/4HANA Cloud or at least a BTP-connected system with modern extensibility in place.
That assumption doesn’t describe most of the installed base. Most SAP customers run ECC 6.0 or a customized on-premise S/4HANA, with decades of Z-code, batch jobs, and integrations that work. Migration is a multi-year, multi-million project — and for many companies it is simply not this year’s priority, or next year’s. Some have extended maintenance plans reaching into the 2030s.
The result is a strange stalemate: the companies with the most data locked inside SAP are the ones told to wait longest for AI. Meanwhile their business users export to Excel, their developers wait for transactions IT hasn’t built, and their competitors experiment.
The gap is not technological. ECC has had HTTP services (ICF) since long before anyone said “LLM.” The gap is a product-strategy decision — and that means it can be routed around.
What SAP announced at Sapphire 2026 — and what the fine print says
At Sapphire 2026, SAP reversed a years-long position and announced that a significant share of Joule assistants and agents will be extended to ECC and on-premise S/4HANA. This was genuinely news: it is SAP acknowledging, publicly, that ECC customers need AI now and cannot all wait for migration.
But the conditions matter more than the headline. Access requires customers to commit the majority of their landscape to RISE with SAP and to purchase the Max Success Plan, SAP’s premium success offering. SAP’s own leadership framed the whole arrangement as an interim solution — a bridge to keep customers on the path to cloud, not a long-term commitment to on-premise AI.
In parallel, SAP’s official ABAP MCP Server now ships inside ADT — both Eclipse (3.60+) and the new VS Code extension — as a developer-side tool whose reach depends on the ADT services your backend exposes. There is no business-user query layer, and no path for older ECC systems without modern ADT services.
Read together, the message to an ECC customer is: you can have AI, if you sign the migration commitment first and pay for the premium plan on top. For companies already planning a RISE move on that timeline, that may be a fine deal. For everyone else, the math is harder:
The prerequisite is the migration itself. The AI is a feature of the commitment, not an alternative to it. If RISE wasn’t justified before, Joule access rarely changes the business case on its own.
“Interim” cuts both ways. Capabilities positioned as bridges get deprecated when the bridge has served its purpose. Building business processes on an explicitly temporary offering carries its own risk.
Scope is SAP-defined. What ships to ECC, and when, follows SAP’s roadmap and eligibility rules — not your requirements.
None of this makes SAP’s move wrong. It makes it conditional — and it leaves the original question open for the majority of the ECC installed base: what about AI now, on the system you actually run, without signing anything?
The three real options for an ECC customer in 2026
Option 1 — Wait for migration. Legitimate if your S/4HANA move is genuinely close and funded. The cost is two to five years of your competitors learning to use AI against their ERP data while your teams export spreadsheets.
Option 2 — Commit to RISE + Max Success for Joule access. Legitimate if RISE already made sense for you commercially. You get SAP-native AI on SAP’s timeline, inside SAP’s eligibility rules, as a bridge offering.
Option 3 — Deploy AI in-system, today. Install an ABAP add-on in a customer-owned namespace, expose a controlled interface through the ICF layer ECC has always had, and connect it to the AI model of your choice through the Model Context Protocol (MCP). No RISE. No BTP. No ADT. No migration prerequisite. This is the approach this guide describes — and the one we built ABAPilot around.
These options are not mutually exclusive. Companies planning a 2028 migration still get two-plus years of value from option 3 in the meantime — and nothing about an in-system deployment interferes with a later move.
What in-system AI on ECC actually looks like
The architecture is deliberately boring, which is exactly what an ECC basis team wants to hear:
Inside SAP: a set of ABAP objects delivered as a standard transport, in the registered /ABAPILOT/ namespace — a customer-owned namespace, not Z-objects. Handler classes attach to a single SICF node. There is no kernel modification, no Gateway add-on, no BTP subscription, and no dependency on ADT or Eclipse — which matters, because much of the open-source AI tooling for ABAP assumes ADT REST APIs that older ECC releases don’t reliably expose.
Outside SAP, on your network: an MCP server, running as a local process or Docker container. MCP — the Model Context Protocol — is the emerging standard for connecting AI models to enterprise systems; it is the same protocol SAP itself adopted for its cloud stack. The MCP server translates between the AI client (Claude, ChatGPT, Cursor, Claude Code, or any MCP-capable tool) and the SAP-side endpoints.
The AI model, wherever you want it: bring your own API key for Claude, OpenAI, Gemini or Amazon Bedrock — or run a fully local model via Ollama so that nothing ever leaves your network. Model choice is a configuration setting, not an architecture decision.
Two things fall out of this design. First, deployment is measured in hours, not months: import a transport, activate a service, start a container. Second, the SAP system remains the system of record and the security authority — the AI layer is a client of SAP, never a bypass of it.
Security: the part your CISO will actually ask about
Any AI-on-ERP conversation lives or dies on three questions.
Who decides what the AI can see? In an in-system design, the SAP authorization model does — the same one you already audit. Every query executes under the calling user’s own authorizations (S_TABU_DIS, S_DEVELOP and the rest are enforced, not reimplemented). If a user can’t see a table in SAPGUI, they can’t see it through the AI. On top of that, an explicit whitelist table defines exactly which endpoints are exposed at all: anything not whitelisted does not exist as far as the AI is concerned.
Where does the data go? Only where you send it. With a cloud model, only the query context you allow leaves your network under your own API agreement; with a local model, nothing leaves at all — a genuine zero-data-retention deployment.
Can we prove what happened? Every request is written to an audit log with user, timestamp and parameters, giving internal audit and compliance a complete trail.
There is also the licensing and policy question that surfaced loudly in 2025–26 around SAP’s API policies and indirect access. An in-system approach is well positioned here precisely because it is ABAP running inside the customer’s own system, in a customer-owned namespace, called by named SAP users under their own authorizations — aligned with SAP’s API policy rather than working around it. (This is a policy-alignment argument, not legal advice; your license terms are your own.)
What teams actually do with it
Business queries in plain language. “Show me vendors with open invoices over €50,000” becomes an answered question in seconds, with the AI joining LFA1 and BSIK on its own, instead of a three-day report request. Finance asks about duplicate payments and open AP by company code; purchasing asks about POs without goods receipt and expiring contracts; audit asks who changed vendor bank details in the last six months.
ABAP development against ECC. The same MCP channel that answers business questions turns Claude Code or Cursor into an ABAP-aware development environment for ECC — code review against best practices, auto-documentation of legacy Z-code, code generation, and multi-agent report development. For teams maintaining twenty years of custom code with a shrinking bench of ABAP developers, this is frequently the bigger win.
A path that survives migration. Because the pattern is in-system ABAP plus MCP, it moves with you: the same approach runs on ECC 6.0 today and on on-premise S/4HANA after conversion.
Frequently asked questions
Can Joule run on SAP ECC?
As of Sapphire 2026, yes — conditionally. SAP announced Joule assistants and agents for ECC and on-premise S/4HANA, but access requires committing the majority of your landscape to RISE with SAP plus the Max Success Plan, and SAP positions it as an interim bridge offering.
Does SAP allow third-party AI tools on ECC?
In-system ABAP in a customer-owned namespace, executed by named users under standard SAP authorizations, is the pattern SAP’s API policy is designed to accommodate. The compliance risks discussed in the ecosystem concern external API consumption and indirect access — a different architecture.
What is an ABAP MCP server?
An MCP (Model Context Protocol) server that exposes SAP/ABAP capabilities to AI clients like Claude or ChatGPT. SAP ships one inside ADT (Eclipse and VS Code) for developer scenarios; ABAPilot provides one for ECC 6.0 and on-premise S/4HANA, with no ADT or BTP dependency.
Do I need to migrate to S/4HANA first?
No. That is the point of the in-system approach: it runs on any ABAP-based SAP instance — ECC 6.0 and above, on-premise S/4HANA, and other NetWeaver-based systems — and carries over if and when you convert.
Get AI running on your ECC system this quarter
ABAPilot is the in-system AI and MCP server described in this guide: an ABAP transport plus a local MCP server, deployed in about two hours, with your choice of AI model and your SAP authorization model in charge. It exists for exactly the companies SAP’s conditions leave out.