# Get AI Value From SAP ECC Now, and Use It to De-Risk the Move to S/4HANA > Source: https://netray.co/erp-ai/sap-ecc-ai-before-2027-migration > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## 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. ## Kind platform ## Erp Family sap ## Erp Products - SAP ECC 6.0 ## Industries - Manufacturing - Aerospace - Defense - Electronics ## Region Global ## Persona CIO ## Eyebrow SAP ECC 6.0 + AI ## Intro 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. ## Pain Points ### Every demo assumes S/4HANA **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** IT leadership needs defensible answers about the ECC timeline now, not once mainstream maintenance is closer to actually ending. ## Use Cases ### Custom code usage mapping **Description:** 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. **Erp Objects:** 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 **Description:** A planner asks which open sales orders are past their requested delivery date, and the agent answers from live order data. **Erp Objects:** 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 **Description:** The agent reads goods-receipt/invoice-receipt mismatches and drafts an explanation for the accounts payable team to review. **Erp Objects:** EKKO, EKBE, MSEG goods movements **Outcome:** shortens the manual GR/IR reconciliation review each accounting period ### Migration interface inventory **Description:** The agent reads IDoc partner profiles and drafts a first-pass current-state interface inventory for the migration team. **Erp Objects:** 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 **Description:** The agent reads existing process documentation and generates draft test scripts for core ECC processes to validate during S/4HANA parallel testing. **Erp Objects:** process documentation, transaction variants, existing test scripts **Outcome:** reduces the manual effort of writing regression test scripts from scratch for cutover ### Quality trend summaries **Description:** The agent reads quality notification history and summarizes recurring defect codes for a management review. **Erp Objects:** QMEL, QMFE, QMUR **Outcome:** turns a quarterly manual pivot-table exercise into an on-demand summary ### Institutional knowledge capture before retirements **Description:** Subject-matter experts walk through custom processes on record; the transcripts and documentation are indexed so the knowledge survives the migration project. **Erp Objects:** process walkthroughs, custom Z-transaction documentation, ABAP comments **Outcome:** keeps institutional knowledge searchable even after the people who hold it move on or retire ## Architecture **Overview:** 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. **Layers:** #### ERP connectors **Detail:** 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. #### Data/semantic layer **Detail:** Replicated read-only tables or InfoSet-based extracts, plus a vector index for documents and ABAP source comments, mapped to existing SAP authorization objects. #### Model serving **Detail:** vLLM or Ollama on customer GPUs or a dedicated private-cloud instance, running an open-weight model sized to ECC's query volume. #### Retrieval/agents **Detail:** 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. #### Governance/audit **Detail:** 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. ## Deployment Options ### Air-gapped on-prem **Fit:** plants and defense suppliers running ECC with no external network path from the ERP segment **Detail:** 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 **Fit:** ECC hosted in a customer-managed private cloud or colocation facility, migrating to S/4HANA on a multi-year timeline **Detail:** 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 **Fit:** central IT wants a single AI layer that survives the ECC-to-S/4HANA transition **Detail:** 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 ### 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. **Framework:** Export control (ITAR, EAR) during migration ### 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. **Framework:** SAP authorization model ### 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. **Framework:** Change control during cutover ### Usage-ranked custom code reports are logged with their source queries, giving the migration steering committee a defensible basis for keep-or-retire decisions. **Framework:** Audit trail for migration decisions ## Integration Notes 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. ## Product Fit ### ERPray **Why:** 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 **Why:** 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. ## Engagement ### Discovery **Duration:** 2-3 weeks **Deliverables:** - 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 ### Pilot **Duration:** 6-8 weeks **Deliverables:** - 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 ### Production **Duration:** 8-12 weeks **Deliverables:** - 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 ### Scale **Duration:** ongoing, through and past cutover **Deliverables:** - 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 ## Buyer Questions - 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? ## Faq ### Is it worth investing in AI on ECC if we're migrating to S/4HANA anyway? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms SAP ECC AI, SAP ECC 6.0 AI integration, AI for SAP ECC, SAP ECC to S/4HANA migration AI, on-prem AI for SAP ECC, SAP ECC mainstream maintenance 2027, SAP ECC custom code AI, SAP ECC copilot, private LLM for SAP ECC, SAP ECC generative AI, SAP ECC RFC AI agent, S/4HANA migration readiness AI --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json