Send us a note or book a short meeting.
For over two decades, custom ABAP has kept SAP landscapes running. Today, that same Z-code legacy stands in the way of cloud transformation. How to decommission the right Z-programs, which ones to modernize, and why CAP applications are the way to meet new requirements.
Z-code isn't the problem in itself. For decades, Z-code was the officially recommended answer to a real requirement: "The standard system doesn't cover our process, so we extend it." Reports, user exits, BAdIs, custom function modules, Z-tables. All of it had its justification, and much of it has run reliably for years.
The problem isn't that Z-code was written. The problem is what happens to it over time:
What was once an asset becomes what the German-speaking SAP community aptly calls "zombie code": technically alive, functionally forgotten, organizationally orphaned.
Three developments are converging right now and turning Z-code cleanup from a "should" into a "must":
The end of maintenance is approaching. Mainstream maintenance for SAP ECC ends in 2027; after that, only paid extended-maintenance options remain available.
SAP is forcing the issue. With the Clean Core level concept (A to D) introduced in August 2025 and further sharpened in early 2026, SAP has created an official classification by which every extension can be categorized. Level A corresponds to ABAP Cloud or side-by-side extensions on BTP. Level D corresponds to classic modifications to the standard, exactly what many existing customers have in their systems. Without a Level A or B architecture, cloud updates can't be consumed reliably.
The market numbers are unambiguous. The DSAG Investment Report 2026 shows that BTP—the platform foundation for CAP and side-by-side development—leads the strategic cloud solutions in the SAP portfolio, with 39 percent of respondents planning high or medium investment. Planned investment in application development and automation on BTP has grown from 17 percent (2024) to 27 percent. The industry is voting with its budget.
And there's a fourth, often overlooked point: no meaningful AI without a clean core. SAP's Joule and the Joule Studio Agent Builder rely on clean, standardized data models and released APIs. Anyone who has extended their core with far-reaching Z-logic can't reliably let AI agents access their data.
CAP stands for Cloud Application Programming Model. It's SAP's official framework for building applications and extensions outside the S/4HANA core. CAP applications are deployed on the SAP Business Technology Platform.
At its core, CAP is a declarative framework: you model your data and services in a simple language (CDS), and CAP automatically generates OData services, database schemas, REST endpoints, and standard logic from it. You write your own business logic in Node.js or Java. The result runs as a decoupled application on BTP and communicates with S/4HANA through official, released APIs.
| Aspect | Z-Code in the Core | CAP on BTP |
|---|---|---|
| Location | In the S/4HANA core | Side-by-side on BTP |
| Upgrade stability | Must be re-checked with every release | Decoupled, its own lifecycle |
| Interfaces | Direct table access | Released APIs, OData |
| Scaling | Tied to the ERP system | Cloud-native, elastic |
| Lifecycle management | Transport system | Git, CI/CD, modern DevOps |
| AI readiness | Difficult | Directly connectable (Joule, MCP) |
| Clean Core level | Typically C or D | Level A |
CAP isn't the only path. ABAP Cloud is the on-stack variant; RAP is the route for Fiori-centric extensions. But for most new requirements—especially when you want to build cross-platform and cloud-native—CAP is the natural default.
Before we talk about project effort, an honest assessment. CAP is powerful, but not every requirement is a CAP project. In consulting conversations, we often arrive at three categories:
1. Check the SAP standard before building anything. Many Z-reports have become obsolete over the years because SAP has since delivered standard functionality for them. The first question is always: can the standard meet the requirements?
2. Use standard extensibility where possible. Key-user extensibility, custom fields, custom logic in Fiori. For many adjustments, that's enough. No code, no project.
3. Use CAP where custom logic is truly needed. When you need your own data models, your own services, complex business logic, or connections to third-party systems—that's the CAP sweet spot.
A rough rule of thumb: if you're thinking about rewriting or modernizing a Z-program today, first ask whether you still need it at all. If you do, it almost never belongs back in the core.
Based on real projects, a first productive CAP use case typically takes 8 to 12 weeks—depending on complexity and integration depth. A proven structure:
Phase 1: Discovery and architecture. We assess the business requirement and the existing Z-code environment. Which standard functions already replace part of it? Which data needs to be read from or written to S/4HANA? Which interfaces are available? Outcome: target architecture and API mapping.
Phase 2: Data model and services. CDS data model, OData services, S/4HANA connection via released APIs. Authentication through XSUAA and IAS. The first endpoints are in place.
Phase 3: Business logic and UI. Implementation of the actual logic in Node.js or Java. UI as SAPUI5/Fiori Elements or as a custom frontend. Integration with workflow or approval processes, if needed.
Phase 4: Integration and testing. Integration tests against the Q system, performance checks, authorizations, end-to-end tests.
Phase 5: Go-live and enablement. Pilot with a defined user group, phased rollout, training for key users, handover to operations.
Important: a one-off CAP project is the beginning, not the goal. The real value emerges once you have a platform setup in which the next requirements take only two to four weeks, because authentication, CI/CD pipelines, and interface catalogs are already in place.
The promise of CAP isn't "everything gets cheaper." The promise is this: your extensions become upgrade-stable and stay compatible with cloud updates. That has value—but value that only shows over several releases.
What you gain:
What to watch out for:
To put it plainly: a CAP project isn't something you do on the side with your existing ABAP team. It requires either building up internal cloud skills or an experienced partner who brings exactly that.
The most common reaction in the SAP community to clean core discussions is resistance, and it's understandable. No one wants to hear that the ABAP skills they've used to keep a company running for over two decades are suddenly "outdated." They aren't. Classic ABAP will remain relevant in many landscapes for years to come, and SAP's Clean Core level model deliberately does away with the binary "clean or dirty" logic.
What it's really about is clarity:
Those who answer these questions in 2026 aren't building a firewall—they're building a bridge: from an existing system that works to a platform architecture that supports AI, cloud updates, and new business models.
At ORAI, we combine deep classic SAP expertise with real BTP and CAP experience. We help you classify your existing Z-code (what stays, what goes, what gets replaced), we deliver your first productive CAP use case in 8 to 12 weeks, and we build the platform setup with you that accelerates every further extension.
