Community Pilot · Edition 2.0

S/4HANA Modernization Assessment & Clean-Core Decision Support

From legacy ABAP inventory to governed target-architecture decisions — a structured path from unknown custom code to architect-reviewed modernization choices.

Author
Felix Frenzel
Platform
Clean-Core.io
Classification
Public · Community Guide
Date
June 2026

Audience: SAP enterprise architects · transformation leads · security reviewers · audit teams · implementation partners

Section 01 / 10

Executive Summary

S/4HANA transformations rarely fail because teams do not understand the Clean Core principle. They fail because legacy systems contain years of custom ABAP, Z tables, direct database reads, unreleased APIs, batch inputs, update tasks, Dynpro logic, RFC dependencies and business-critical exceptions that are difficult to classify.

Clean-Core.io helps teams turn this uncertainty into a structured modernization backlog. The platform analyzes legacy custom code, identifies technical and compliance risks, recommends a Clean-Core target pattern and generates reviewable implementation drafts.

The Goal

Not automatic production migration — but a faster, more transparent path from unknown legacy custom code to architect-reviewed modernization decisions.

What it is

A prototyping, assessment and governance accelerator — fast enough for exploration, structured enough for governance, honest enough for enterprise review.

What it is not

A replacement for enterprise-architecture approval, SAP release checks, privacy review, penetration testing or production migration governance.

Section 02 / 10

What Clean-Core.io Produces

Clean-Core.io is an accelerator for governed modernization work. Code generation is valuable — but the decision evidence around it is what enterprise teams trust.

01

A modernization assessment before transformation starts.

02

A custom-code and integration-risk inventory.

03

A Clean-Core decision tree with recommended target architecture.

04

Draft implementations for RAP, CAP or integration patterns.

05

Test stubs and validation checklists.

06

BPMN / SOP documentation for business review.

07

A compliance and audit pack per project.

Section 03 / 10

Modernization Assessment Before Transformation

Before any refactoring starts, the platform creates a project assessment report — a shared view of what exists, how risky it is, and which target architecture fits.

Custom-code inventory

Programs, classes, function modules, includes, exits, enhancements, forms, tables and generated artifacts.

Table access analysis

Direct SELECT / UPDATE / INSERT / DELETE usage, joins on SAP standard tables, Z-table dependencies and data-ownership risks.

API & release analysis

Released APIs, unreleased APIs, private classes, obsolete function modules and compatibility concerns.

Legacy pattern findings

Dynpro, RFC, update task, batch input, BAPI, user exits, implicit enhancements and background jobs.

Complexity scoring

Size, coupling, number of dependencies, critical table access, testability and modernization effort.

Business criticality

Process area, user volume, frequency, financial impact, regulatory relevance and operational fallback.

Recommended target architecture

Key User Extensibility, Developer Extensibility / RAP, Side-by-Side CAP, Integration Suite, Event Mesh or Retire.

Section 04 / 10

Clean-Core Decision Tree

A decision tree explains why a recommendation was made — and which alternatives were rejected.

Key User Extensibility
Use when: Field additions, simple validations, UI adaptations and low-risk process variants via released in-app tooling.
Avoid when: Logic is complex, integration-heavy or needs custom lifecycle control.
Output: Configuration guidance and implementation checklist.
Developer Extensibility / RAP
Use when: Logic belongs close to S/4HANA, needs transactional consistency and can use released ABAP Cloud APIs.
Avoid when: Scenario depends on unreleased objects or external channels dominate the design.
Output: RAP BO draft, CDS / service model, ABAP Unit stubs.
Side-by-Side CAP
Use when: Process can be decoupled, needs independent release cycles, external UX or cloud-native integration.
Avoid when: Tight synchronous locking or direct core updates are required.
Output: CAP service draft, data model, API facade and test suite.
Integration Suite
Use when: Main problem is orchestration, API mediation, mapping, routing or partner connectivity.
Avoid when: Custom business state and complex domain logic are central.
Output: Integration-flow blueprint, mappings and monitoring controls.
Event Mesh
Use when: Benefits from asynchronous decoupling, event-driven updates and loose consumer coupling.
Avoid when: Immediate consistency and synchronous confirmation are mandatory.
Output: Event model, topic design and subscriber contract.
Retire
Use when: No usage, duplicate functionality, or replaceable by standard SAP capability.
Avoid when: Business ownership or audit retention is unclear.
Output: Retirement proposal, validation checklist and decommission plan.
Section 05 / 10

Compliance & Audit Pack Per Project

Enterprise customers need evidence. Every project export includes an audit pack documenting what the platform saw, what it decided, and what limitations remain.

Input fingerprint

Timestamp, uploaded file hash, project ID, user / tenant context and processing configuration.

Mapping rules

Source patterns, matched rules, confidence levels, rejected alternatives and manual override notes.

Model evidence

Model / provider, prompt-template version, policy version, settings and generation timestamp.

Review checklist

Architecture, security, privacy, SAP release check, test evidence and owner sign-off.

Known limitations

Unsupported ABAP constructs, incomplete metadata, assumptions and low-confidence mappings.

Data protection & tenant notes

Processing region, storage scope, credential handling, retention / deletion status and BYOK status.

Downloadable with the implementation ZIP — the bridge between prototype speed and enterprise governance.

Section 06 / 10

Security & Data Handling

The security model is described as implemented controls, intended scope and review boundaries — not as unconditional guarantees. This wording fits enterprise procurement expectations.

Use non-production or representative code for the public pilot, unless a customer-specific agreement is in place.

Keep AI-provider keys, platform secrets and tenant credentials separated by responsibility and storage boundary.

Store only what the workflow requires, and define retention and deletion behavior clearly.

Document which data is sent to AI providers, which region processes it, and which contractual terms apply.

Make tenant connectivity read-scoped by design where possible, admin-approved and auditable.

Treat generated output as draft material that requires expert review before production use.

Section 07 / 10

Reference Workflow

01

Upload a legacy ABAP package, representative extract or code sample.

02

Generate the modernization assessment and risk inventory.

03

Review findings by object, process area and risk category.

04

Use the Clean-Core decision tree to choose the target pattern.

05

Generate a draft implementation and test scaffold.

06

Validate APIs, tenant metadata and business assumptions.

07

Export the delivery package and compliance / audit pack.

08

Complete expert review before productive implementation.

Section 08 / 10

Example Findings

Direct SELECT on KNA1
Risk: Upgrade fragility and unreleased data dependency.
Path: Replace with released customer API / CDS view where suitable.
Direct access to BSEG
Risk: High financial and performance risk.
Path: Use released journal-entry interfaces and explicit finance review.
Batch input for transaction flow
Risk: UI coupling and fragile automation.
Path: Replace with released APIs, RAP behavior or integration flow.
Update-task function module
Risk: Hidden side effects and transaction coupling.
Path: Redesign transaction boundary and test failure behavior.
Unused Z report
Risk: Maintenance cost without value.
Path: Validate usage and retire.
Section 09 / 10

Quality Engineering

Modernization is not complete when code compiles. The platform generates test and review evidence:

Unit-test stubs for generated RAP / CAP drafts.

API contract checks and schema validation.

Security review checklist for credentials, authorization and data flow.

Business SOP and BPMN export for process owners.

Clean-Core score and remediation backlog.

Manual-review gates for low-confidence mappings.

Section 10 / 10

Start with a non-production sample

Use Clean-Core.io to create the first modernization assessment, review the decision tree with your SAP architect and export a governed delivery package for the next implementation step.

Clean-Core.io is a practical accelerator for expert teams: fast enough for exploration, structured enough for governance and honest enough for enterprise review.

FF
Felix Frenzel
Founder & Community Architect · Bamberg, Germany