SAPERP Platform

SAP ECC 6.0 + AI

Get AI Value From SAP ECC Now, and Use It to De-Risk the Move to S/4HANA

Short answer

SAP ECC 6.0 customers do not have to wait for an S/4HANA go-live to get generative AI value: a private LLM can ground itself in ECC's existing BAPIs, IDocs, and ABAP tables today, and the same discovery work becomes evidence for the S/4HANA migration itself. With mainstream maintenance for ECC 6.0 set to end in 2027, most IT organizations are deciding whether to convert, re-implement, or delay, and AI can help answer that question while reducing the manual effort of cutover.

ERP: SAP ECC 6.0
Industries: Manufacturing, Aerospace, Defense, Electronics
Written for: CIO

Discuss your SAP ECC 6.0 environment See use cases

If you are running SAP ECC 6.0 with an S/4HANA migration somewhere on a multi-year roadmap, you have probably noticed that almost every AI vendor demo assumes S/4HANA and Fiori. That leaves the system you actually run today, and the transactions your teams actually use every day, treated as an afterthought in every pitch.

The pressure is real but not urgent enough to force a decision: SAP has set 2027 as the end of standard mainstream maintenance for ECC 6.0, with an extended maintenance option available afterward for an additional fee. Most migration programs run two to four years end to end once scoping, custom code assessment, and cutover testing are included, which means the AI question and the migration question are really the same planning conversation.

The reframe worth making: retrieval-augmented generation and agents work fine on ECC's existing RFC, BAPI, and IDoc surface right now. Grounding a private model in that data delivers value on the system you run today, and the discovery work involved, mapping custom code usage, documenting interfaces, cataloguing Z-transactions, feeds directly into migration scoping instead of being thrown away at cutover.

This page covers both sides: what AI can do for ECC today, and how the same investment reduces the manual effort and risk of the eventual S/4HANA migration.

What usually gets in the way

The problems we hear most from cio teams running SAP ECC 6.0.

Every demo assumes S/4HANA

AI vendors build for Fiori and S/4HANA by default, even though ECC 6.0 on SAP GUI is still where most transactions in a lot of manufacturing landscapes actually happen.

Custom code knowledge is walking out the door

Years of Z-transactions, custom BAdIs, and user-exits exist mainly in the heads of a shrinking group of long-tenured consultants and employees, many of whom are approaching retirement.

AI value keeps getting deferred

The business case for AI keeps getting pushed to 'after we move to S/4HANA,' which delays real ROI by years on a migration timeline that itself keeps slipping.

No clean map of what custom code is used

Nobody has a current, evidence-based view of which Z-transactions are actually used and by whom, which slows every migration scoping workshop into a series of guesses.

2027 puts a real date on a decision that keeps getting punted

IT leadership needs defensible answers about the ECC timeline now, not once mainstream maintenance is closer to actually ending.

Where AI earns its place in SAP ECC 6.0

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Custom code usage mapping

The agent reads usage statistics and ABAP source to flag which Z-transactions are actually used and by whom, ahead of running a Custom Code Migration app or Readiness Check.

Touches: ST03N usage data, SE16N table access logs, custom Z-transactions, ABAP source

Outcome: gives the migration scoping team a usage-ranked list instead of guessing which custom code to keep

Natural-language question answering on live ECC data

A planner asks which open sales orders are past their requested delivery date, and the agent answers from live order data.

Touches: BAPI_SALESORDER_GETLIST, VBAK, VBAP, VBEP

Outcome: gives planners a working copilot on the system they use today, with no need to wait for the S/4HANA go-live

GR/IR exception drafting

The agent reads goods-receipt/invoice-receipt mismatches and drafts an explanation for the accounts payable team to review.

Touches: EKKO, EKBE, MSEG goods movements

Outcome: shortens the manual GR/IR reconciliation review each accounting period

Migration interface inventory

The agent reads IDoc partner profiles and drafts a first-pass current-state interface inventory for the migration team.

Touches: WE20 partner profiles, IDoc types ORDERS05/DESADV/INVOIC, interface mapping documentation

Outcome: produces a first-pass interface inventory in days instead of weeks of cross-functional workshops

Regression test script drafting

The agent reads existing process documentation and generates draft test scripts for core ECC processes to validate during S/4HANA parallel testing.

Touches: process documentation, transaction variants, existing test scripts

Outcome: reduces the manual effort of writing regression test scripts from scratch for cutover

Quality trend summaries

The agent reads quality notification history and summarizes recurring defect codes for a management review.

Touches: QMEL, QMFE, QMUR

Outcome: turns a quarterly manual pivot-table exercise into an on-demand summary

Institutional knowledge capture before retirements

Subject-matter experts walk through custom processes on record; the transcripts and documentation are indexed so the knowledge survives the migration project.

Touches: process walkthroughs, custom Z-transaction documentation, ABAP comments

Outcome: keeps institutional knowledge searchable even after the people who hold it move on or retire

Reference architecture

The architecture is built around ECC's classic integration surface, RFC-enabled function modules, BAPIs, and IDocs, with a connector abstraction designed so the same retrieval and agent layer can be repointed at S/4HANA's OData and CDS layer once cutover happens.

1
ERP connectors
RFC-enabled function modules and BAPIs such as BAPI_SALESORDER_GETLIST, IDoc listeners for event data, and, where already exposed, SAP Gateway OData services on Fiori-enabled ECC systems.
2
Data/semantic layer
Replicated read-only tables or InfoSet-based extracts, plus a vector index for documents and ABAP source comments, mapped to existing SAP authorization objects.
3
Model serving
vLLM or Ollama on customer GPUs or a dedicated private-cloud instance, running an open-weight model sized to ECC's query volume.
4
Retrieval/agents
RAG grounding plus an agent layer whose tools are scoped to specific RFC and BAPI calls, so it cannot go beyond what those function modules expose.
5
Governance/audit
Query and answer logging, role mapping to existing SAP authorization objects, and a migration-specific evidence trail of which custom code was actually queried, by whom, and how often.

Integration notes for your ERP team

RFC-enabled function modules, whether custom or standard BAPIs, are the primary read path on classic ECC; where none exists for a needed dataset, a thin custom RFC wrapper is usually less work than a full interface.
IDoc partner profiles in WE20 and standard IDoc types already carry most of the event data an agent needs, such as order creation, delivery, and invoicing; the AI layer subscribes to these rather than polling tables.
SE16N table browsing is useful during discovery to understand table structures, but it should not be the AI's primary read path in production.
Where ECC already exposes OData services through SAP Gateway, common on Fiori-enabled ECC systems, those are preferred over raw RFC for the same authorization and maintainability reasons as on S/4HANA.
Authentication uses a dedicated RFC or communication user with authorizations scoped to the exposed function modules, following existing Basis conventions for interface users.
Building the retrieval and agent layer against a connector abstraction, rather than directly against ECC RFC calls, means the same AI layer can be repointed at S/4HANA's CDS and OData layer post-migration with a connector swap, not a rewrite.

Deployment options

Air-gapped on-prem

plants and defense suppliers running ECC with no external network path from the ERP segment

GPU serving is co-located with the existing ECC application servers; RFC calls stay inside the network and nothing crosses to a public API.

Private/sovereign cloud

ECC hosted in a customer-managed private cloud or colocation facility, migrating to S/4HANA on a multi-year timeline

The model and RAG index run in the same private tenancy as ECC, with the architecture designed to be repointed at S/4HANA's OData and CDS layer once cutover happens.

Hybrid

central IT wants a single AI layer that survives the ECC-to-S/4HANA transition

A connector abstraction separates the agent and retrieval logic from the ECC-specific RFC calls, so swapping in S/4HANA's OData services later is a connector change, not a rebuild.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

Export control (ITAR, EAR) during migration

Keeping the AI layer on-prem avoids adding a new SaaS data path for ECC material master and BOM data while the migration project is already under security review.

SAP authorization model

RFC calls run under a service user scoped to the same authorization objects users already have, so migration documentation generated by the AI does not expose data beyond a user's existing access.

Change control during cutover

Any AI-assisted documentation or test scripts feed into existing change management and testing sign-off; they do not bypass it or replace the project's own quality gates.

Audit trail for migration decisions

Usage-ranked custom code reports are logged with their source queries, giving the migration steering committee a defensible basis for keep-or-retire decisions.

Where Netray fits

ERPray

Read-only question-answering over ECC's BAPI, IDoc, and table surface, with the underlying RFC call shown, fits ERPray's grounded-answer model on any supported ERP, including ECC.

Custom build

Migration-specific work such as custom-code usage mapping, interface documentation generation, and cutover test-script drafting is project-specific and typically needs a scoped custom build.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery

-Inventory of RFC-enabled function modules, BAPIs, IDoc types, and any existing OData services
-Custom code and Z-transaction usage baseline
-Migration timeline alignment on what needs to survive cutover versus what is throwaway
-GPU and hosting sizing estimate

Phase 2 . 6-8 weeks

Pilot

-Read-only agent for one or two priority use cases on live ECC data
-Custom-code usage report for the migration scoping team
-Accuracy review with planners, buyers, and quality engineers
-Go/no-go criteria for production

Phase 3 . 8-12 weeks

Production

-Hardened ECC-facing deployment with role-mapped access
-Migration documentation and test-script generation workflow
-Monitoring and audit export
-Connector abstraction documented for the eventual S/4HANA swap

Phase 4 . ongoing, through and past cutover

Scale

-Additional ECC use cases onboarded
-Connector repointed to S/4HANA's OData/CDS layer at go-live
-Continuity validation so the same AI layer keeps working post-migration
-Usage and ROI reporting across the transition

Questions to ask any vendor, including us

A short list that separates real SAP ECC 6.0 AI work from a chatbot demo.

Will this AI investment carry forward into S/4HANA, or is it thrown away at cutover?
Does the vendor's roadmap assume S/4HANA, and if so, what happens to our ECC timeline in the meantime?
How is custom code usage actually measured, versus guessed from documentation?
What RFC and BAPI calls does the agent use, and can Basis review the exact list?
Does any ECC data leave our network for this to work?
How does this integrate with our existing SAP Readiness Check or Custom Code Migration app findings?
What's the realistic timeline to see value on ECC, versus waiting for the S/4HANA go-live?

Frequently asked questions

Is it worth investing in AI on ECC if we're migrating to S/4HANA anyway?

Usually yes, for two reasons. Most ECC to S/4HANA migrations take two to four years end to end, and a private LLM grounded in your existing BAPIs and IDocs delivers value on the system you actually run today. Second, the same discovery work, custom code usage mapping and interface inventory, doubles as migration evidence, so the investment is not wasted at cutover if the connector layer is built to be swapped rather than rebuilt.

When does SAP ECC 6.0 mainstream maintenance actually end?

SAP has set 2027 as the end of standard mainstream maintenance for ECC 6.0, with an extended maintenance option available afterward for an additional fee for customers who need more runway. Exact terms and any further extensions should be confirmed directly with SAP for your specific contract, since maintenance policies have shifted before.

Can AI help decide what custom code to keep during migration?

It can help gather the evidence: usage statistics on which Z-transactions are actually called and by whom, and plain-language explanations of what a piece of ABAP does, pulled from source and comments. The keep-or-retire decision still belongs to the migration steering committee, but AI-assisted usage mapping replaces a lot of manual SE16N digging and interview-based guesswork.

Does this work on RFC-based ECC without any OData services?

Yes. RFC-enabled function modules and existing BAPIs are the standard read path on classic ECC, and IDocs provide event data. Where ECC already has SAP Gateway OData services, common on Fiori-enabled ECC systems, those are used instead, for the same reasons they are preferred on S/4HANA.

Will we have to rebuild the AI layer when we go live on S/4HANA?

Not if the connector layer is separated from the retrieval and agent logic during the ECC phase. The RFC and BAPI calls get swapped for OData and CDS calls, but the retrieval index structure, the agent's use cases, and the governance layer carry forward with configuration changes rather than a rebuild.

How does this help de-risk the migration itself, not just add AI features?

Custom-code usage mapping, interface documentation generation, and draft regression test scripts are all migration deliverables that normally consume weeks of manual workshop time. Generating a first pass of each with AI, reviewed by the project team, shortens the scoping and testing phases that are usually the biggest source of migration schedule slip.

What ECC data is safe to use for retrieval in a defense or export-controlled environment?

The same rule applies as with any AI deployment on export-controlled ERP data: the model and retrieval index run inside your existing network boundary, so material master, BOM, and technical data used for grounding never cross to a public API. This keeps the AI layer inside the same assessment boundary as the rest of your ECC environment.

Related guides

SAP S/4HANA + private AI

AI for SAP S/4HANA, Running On-Prem or in Your Private Cloud

Run AI on SAP S/4HANA without sending ERP data to a public API. On-prem and private-cloud architecture, CDS views, OData, and honest deployment trade-offs.

SAP BTP + self-hosted AI

SAP BTP and a Private LLM: Where the Generative AI Hub Fits and Where It Doesn't

Where SAP BTP's Generative AI Hub fits and where a self-hosted LLM belongs instead. CAP, Integration Suite, and an architecture decision framework.

SAP Joule + on-prem alternative

SAP Joule or a Private LLM Beside SAP: An Honest Comparison

An honest comparison of SAP Joule and Business AI against a private, self-hosted LLM beside SAP: what each covers, where they overlap, and where CIOs run both.

ERP migration + on-prem AI

AI-assisted data migration for ERP implementations

AI speeds ERP data migration by profiling legacy data, proposing field mappings, and flagging cleansing issues before cutover, with a human validating every rule.

ERP AI Cost Guide

What ERP AI Actually Costs: A CFO's Guide

A CFO's guide to what ERP AI actually costs: GPU hardware, model licensing, integration and connector work, and realistic ongoing run-rate ranges.

ERP AI readiness

Is Your ERP Ready for AI? A Readiness Assessment Checklist

Is your ERP actually ready for AI? A practical checklist covering master data quality, access and permissions, GPU sizing, and governance before you fund a pilot.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows SAP ECC 6.0

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides