Use cases
Clean Core, demonstrated
These are illustrative scenarios with sample figures — representative of typical mid-size SAP engagements, not named-client results. They show the Clean Core patterns and the kind of outcomes we target.
Released APIs
official, upgrade-safe interfaces instead of direct table writes
RAP & OData
modern app framework instead of brittle screen-scraping (BDC)
Fiori Elements
modern web UI instead of old GUI screens (Dynpro)
ATC gate
SAP's code-quality check, so the clean core stays clean
−96%
Prio 1/2 cloud-readiness findings
0
new findings merged past the CI gate
15 yrs
of custom code triaged in 10 weeks
Discrete manufacturing
10-week assessment + remediation sprint
From 4,200 ATC findings to a green cloud-readiness gate
The upgrade was stalled and nobody knew why: a mid-size manufacturer had ~4,200 ATC findings (issues flagged by SAP's code-quality checker) under the ABAP_CLOUD_DEVELOPMENT_DEFAULT variant across 15 years of custom ABAP, with no way to tell which ones actually blocked their S/4HANA move.
The Clean Core approach
- 1 Baselined the existing findings so the team could see net-new risk separately from legacy debt.
- 2 Sorted findings worst-first by Clean Core weight — direct table writes and modifications ahead of cosmetic issues.
- 3 Replaced SAP-table writes with released BAPIs and RAP EML; reads moved to released I_* CDS interface views.
- 4 Pinned new packages to ABAP for Cloud Development so violations fail at compile time, and wired an ATC gate into the transport workflow.
Clean Core compliance
- All custom writes routed through released APIs / RAP EML — no direct SAP-table updates remain.
- New development pinned to Restricted ABAP, enforced at compile time.
- ATC ABAP_CLOUD_DEVELOPMENT_DEFAULT gate blocks regressions in the transport pipeline.
“We finally knew which findings actually mattered — and watched the dangerous ones go to zero.”
Learn the techniques
−100%
screen-scraping / CALL TRANSACTION calls
3×
faster nightly load, set-based not screen-by-screen
0
duplicate orders since the idempotency key
Wholesale distribution
6-week modernization sprint
Retiring a fragile BDC integration with RAP and OData
A core nightly process was one screen change away from failure: sales orders were created by a BDC job (brittle screen-automation scripts) that replayed the VA01 transaction overnight. It broke on every UI change, had no error recovery, and was a hard blocker for ABAP Cloud, SAP's cloud-safe model (CALL TRANSACTION isn't available there).
The Clean Core approach
- 1 Mapped the BDC steps to the released sales-order API and modelled the interface as a RAP business object.
- 2 Exposed an OData service for inbound orders with validation, determinations, and per-record error handling.
- 3 Made the load idempotent with an external-reference key so retries can't create duplicates.
- 4 Added application logging through the released log API for full observability.
Clean Core compliance
- No batch-input or CALL TRANSACTION — the interface is ABAP-Cloud-ready.
- Business logic invoked through released APIs and RAP behavior, not UI replay.
- Observable and idempotent: released logging plus a dedup key on every record.
Learn the techniques
~0
lines of hand-written UI code
−80%
custom logic, after CDS pushdown
Any device
browser access, GUI no longer required
Utilities
8-week migration
A 3,000-line module-pool report reborn as a Fiori app
Operations were tethered to the desktop SAP GUI: a core report lived in a 3,000-line module pool (old-style GUI program) with embedded business logic and a full-screen ALV grid. It couldn't run outside the GUI and blocked the team's move to Fiori, SAP's modern web UI.
The Clean Core approach
- 1 Lifted the data model into layered CDS views (basic → composite → consumption) with the calculations pushed down.
- 2 Wrapped transactional behavior in a managed RAP business object with released determinations and validations.
- 3 Generated a Fiori Elements List Report / Object Page — no hand-written UI5 controller code.
- 4 Kept one unavoidable legacy routine behind a released interface in its own software component.
Clean Core compliance
- UI is metadata-driven Fiori Elements over OData — no Dynpro, no module pool.
- Data model is layered CDS with code pushdown to HANA.
- Legacy code isolated in its own component behind a released interface.
“The same report now opens on a tablet on the plant floor — and the code is a fraction of the size.”
Learn the techniques
−92%
pricing-run wall-clock time
1
set-based read replacing 100k+ round-trips
Back inside
the nightly batch window
Retail
4-week performance engagement
Killing N+1 reads in a pricing run on HANA
A nightly job was about to miss its deadline: a daily pricing run looped over articles and fired a separate database query (a SELECT *) per article — hundreds of thousands of round-trips. Runtime had crept past the batch window (its overnight time slot) and was getting worse each quarter.
The Clean Core approach
- 1 Replaced the per-row reads with a single set-based read, projecting only the needed columns.
- 2 Pushed the aggregation and currency conversion down into a CDS view instead of looping in ABAP.
- 3 Removed SELECT * everywhere on the hot path and added the right secondary access paths.
- 4 Captured the pattern as a reusable cookbook so the team avoids the N+1 trap next time.
Clean Core compliance
- Set-based SQL with projected columns — no SELECT * on hot paths.
- Calculations pushed down to CDS instead of ABAP loops.
- Reusable performance pattern documented for the team.
Learn the techniques
0
modifications left in the digital core
Independent
release cadence for the extension
Upgrade-safe
core upgrades no longer regress the workflow
Professional services
12-week side-by-side build
A custom approval app moved side-by-side onto BTP
Every upgrade had become a regression project: a bespoke multi-step approval engine had grown tangled into SAP's standard objects. The team wanted it out of the core (off SAP's standard system, so upgrades stay clean) without losing functionality.
The Clean Core approach
- 1 Rebuilt the engine as a side-by-side service on the SAP BTP ABAP environment.
- 2 Connected it to S/4HANA through released OData services and business events — no point-to-point RFCs.
- 3 Replaced the in-core modifications with key-user extensions and released BAdIs where logic had to stay on-stack.
- 4 Documented a clear release contract at the component boundary for what's exposed.
Clean Core compliance
- Extension runs side-by-side on BTP, connected only through released interfaces and events.
- Remaining on-stack logic uses key-user extensibility and released BAdIs — zero modifications.
- A documented release contract governs the component boundary.
Learn the techniques
−65%
small-change tickets reaching developers
Same-day
turnaround on routine field requests
No new
Z objects for in-app changes
Consumer goods
5-week enablement
Empowering key users to extend without a single Z object
The business waited on developers for trivia: every small change — a custom field, a validation, a tweak to a Fiori app — became a developer ticket and a transport (a controlled change moved between systems), slowing the business and growing the custom-code (Z) footprint.
The Clean Core approach
- 1 Inventoried the recurring requests and sorted which truly needed a developer versus key-user tooling.
- 2 Set up custom fields, custom CDS, and key-user BAdIs through the in-app extensibility tools (Tier 1).
- 3 Trained key users with the Academy's business tracks so they own routine changes safely.
- 4 Defined a guardrail for when to escalate from Tier 1 to developer extensibility.
Clean Core compliance
- Routine extensions delivered through key-user (Tier 1) tooling — no classic development.
- Custom fields and logic sit beside the core, upgrade-safe by design.
- A clear tier-escalation guardrail keeps changes at the lowest safe tier.
Picture your codebase here
Bring us your hardest custom-code problem. We'll show you the released, low-risk path to a clean S/4HANA core — and prove it on your landscape.