Updated 10 September 2026. This article replaces our earlier migration-timing opinion with a practical custom-code assessment workflow.
Before estimating an ECC-to-S/4HANA custom-code project, establish which developments are needed, what changes for the target release and how the business will verify the result. A count of custom objects is a starting point, not a reliable estimate of remediation effort.
This guide focuses on custom ABAP assessment. It is not a complete system-conversion plan: data migration, process redesign, infrastructure, authorisations and cutover need their own workstreams.
1. Define the target before running checks
Record the intended S/4HANA edition and release, conversion approach and development constraints. Check the prerequisites of the analysis tools against your actual landscape. Findings for one target release or deployment model should not be treated as approval for another.
Use the SAP custom code analysis documentation to choose an appropriate analysis setup. SAP distinguishes general custom-code analysis from the Custom Code Migration app used for S/4HANA migration.
2. Build an inventory with owners and usage evidence
For each development, record its purpose, business owner, technical dependencies and where it is used. Include scheduled and infrequent processes in the review. A short observation period may miss a year-end report or an exception-handling transaction.
SAP’s Custom Code Migration documentation describes using collected usage data to identify unused code. Treat that evidence as input to a retirement decision: confirm with the process owner before removing an object.
3. Analyse compatibility with the target release
SAP’s custom code migration workshop explains using ABAP Test Cockpit (ATC) checks for SAP S/4HANA simplifications and SAP HANA-related changes. Use the applicable check configuration and current prerequisites for the chosen target.
Keep a reproducible record of the analysed scope, target, check configuration, run date and findings. Review dependencies and the business impact of findings before estimating work. A static finding and a runtime defect are different types of evidence.
- Inventory: objects, owners, dependencies and usage.
- Assessment: target-specific checks and findings.
- Decision: retire, retain, adapt or redesign.
- Verification: implementation evidence and business scenarios.
Each decision should point back to its evidence and responsible reviewer.
4. Make an explicit decision for each development
- Retire: the business confirms it is no longer required and dependencies have been reviewed.
- Retain: it is still required, with the applicable compatibility and business checks recorded.
- Adapt: bounded changes can preserve the required behaviour on the target.
- Redesign: the process or extension approach needs a different implementation.
These are planning categories, not automatic conclusions from an AI response. Record why the decision was made, who approved it and which assumptions remain open. Do not interpret “no findings” as proof that all business scenarios work.
5. Define tests before remediation
Capture representative inputs and expected outputs for critical processes. Agree which checks run at method level and which require interfaces, batch jobs, authorisations or user interaction. Assign business acceptance responsibilities before implementation begins.
After a change, retain the source diff, check results, test evidence and updated specification. Keep scenarios that were not executed visible in the handover. Our ABAP change-delivery checklist provides a reusable structure for that evidence.
Where AI assistance can help—and what it does not establish
An AI assistant can help explain existing code, draft documentation, organise findings and propose test scenarios when it receives the relevant context. Review every output against the sources and your project requirements.
ABAPilot by Crimson Consulting connects compatible AI clients to a separately licensed SAP backend. Its public connector and demonstrated development workflows do not establish that a customer’s custom code is migration-ready. Use the required SAP checks and target-system validation independently.
Our recorded sandbox example shows a report change, 14 passing unit methods and updated documents. It is not an ECC-to-S/4HANA migration demonstration; manual report integration was not executed. Read the AI for SAP ECC guide for evaluation criteria on an existing landscape.
A useful first assessment deliverable
Start with one representative process and its dependent custom objects. Produce a short assessment containing:
- Target release and scope boundaries.
- Object inventory, usage evidence and process owners.
- Check findings with severity and business impact reviewed.
- Retire, retain, adapt or redesign decisions and their rationale.
- Test scenarios, dependencies, open questions and estimate assumptions.
Use this sample to calibrate the broader assessment. Avoid promising a migration date or savings from object counts alone.
Discuss a custom-code assessment with Crimson Consulting. Bring a description of the process and your intended target; confidential code or credentials are not needed for the initial conversation.
SAP references checked 10 September 2026. Follow the documentation for your target release and installed tool versions. This article is written by Crimson Consulting, the vendor of ABAPilot.