Lesson 4 of 5
Adaptation
12 min
Listen to this lesson
Adaptation is where findings become changes. It has two strands that are easy to confuse. Modifications and enhancements to SAP objects are adjusted with the familiar upgrade tools. Custom code that uses simplified functions or data is fixed using the readiness findings. Both happen in the converted development system first, and both end up in transports for the later conversions.
Modifications: SPDD and SPAU
SAP's conversion guide says you adapt modifications and enhancements with the standard transactions SPDD, SPAU and SPAU_ENH, as in previous upgrades, with renewed tools. SPDD covers dictionary objects and is handled during the SUM run, because the database structures must be right before data is converted. SPAU and SPAU_ENH cover programs and enhancements afterwards. The adjustments are recorded in transports that SUM can include in the conversions of the following systems, so the work is done once.
Order of work. In SPAU, process SAP Note corrections first. Many notes implemented in ECC are already part of SAP S/4HANA 2025, and SPAU shows them as obsolete so you can reset them instead of adjusting them. Then handle modifications made with the Modification Assistant, which SPAU can often adopt semi-automatically, and finally those made without it, which need a manual comparison in version management. In SPDD, decide per modified dictionary object whether to keep the modification or return to SAP standard. Customer append structures are enhancements, not modifications, but check them for field name clashes with fields SAP added.
- Sandbox conversionFirst look: SPDD and SPAU volumes, readiness findings in a converted system
- Development conversion (CMD)SPDD during SUM, SPAU and SPAU_ENH after; fixes made and transported
- Local ATC runS4HANA_READINESS variant in CMD until no errors remain in scope
- Quality conversion (CMQ)Transports from CMD applied with SUM; testing starts
- Production conversion (CMP)Same transports applied; no new development on the weekend
Simplification findings and quick fixes
For readiness findings, SAP recommends the ABAP Development Tools for Eclipse (ADT), not SE80, which no longer supports every development object SAP S/4HANA uses, such as CDS views. ADT offers quick fixes: proposals the developer can apply to a finding in the editor, and mass quick fixes that adapt whole packages in one go. SAP names typical cases quick fixes cover, including the material number and amount field length extensions, changes to the SD document category field, and data model changes such as pricing conditions and the old sales status tables.
| Approach | When to use it | Watch out for |
|---|---|---|
| Mass quick fix | Same pattern in many objects, quick fix available | Review a sample of changes; run ATC and unit tests on the package afterwards |
| Single quick fix | Quick fix available but the context is unusual | Read the proposed change; do not accept it blindly |
| Manual change | No quick fix, or the logic itself must change | Read the SAP Note for the simplification item first |
| Replace with standard | A released API, CDS view or app now does the job | Behavior differences: compare outputs with ECC |
| Retire late | Analysis shows the object is not worth adapting | Owner agreement, as in scoping |
Quick fixes are a large saving, but they are proposals, not proofs. A quick fix that widens a variable to the new material number length is almost always safe. One that rewrites a database access to the new data model is more delicate: it may return rows in a different order, or include records the old code never saw. The more a quick fix touches data access, the more the change needs a test that compares results, which lesson 5 covers.
| ECC pattern in custom code | What changed in SAP S/4HANA | Typical fix |
|---|---|---|
Reads VBUK / VBUP for document status | Status fields moved into the document header and item tables, such as VBAK and VBAP | Read the status from the document tables; quick fix for many simple reads |
Reads KONV for pricing conditions | Document conditions are stored in PRCD_ELEMENTS | Read the new table or a released API; quick fix for simple SELECTs |
| Material number in 18-character variables, offsets or concatenations | Material number field extended to 40 characters | Type with the data element; quick fix for declarations; check offsets and fixed-length layouts by hand |
| Compares the SD document category with one-character values | SD document category extended from 1 to 4 characters | Use the new data type; quick fix available for many cases |
Writes to MKPF / MSEG | Material documents stored in MATDOC; the old tables are compatibility views | Post through a BAPI or released API; reads still work, but check performance |
Patterns behind most of Contoso’s findings. The SAP Note attached to each finding is the authority for your release.
A mass quick fix, step by step
- In ADT, run ATC on the package with the readiness variant, or open the results of the central run.
- In the ATC Problems view, filter to one finding type, for example the material number length findings.
- Select the findings and apply the recommended quick fixes together; review the proposed changes in the wizard before you confirm.
- Activate, record the changes in the package’s adaptation transport, and re-run ATC on the package.
- Review a sample of the changed objects (Contoso’s rule: at least one in ten, and every object with offsets or file layouts).
- Record the adaptation type, mass quick fix, against each object so lesson 5 can set its test depth.
Discipline during adaptation
- Change only what the finding requires. A conversion is not the moment for unrelated refactoring.
- Keep transports small and named by package and finding type, so they can be traced and re-sequenced.
- Freeze or tightly control new development in ECC during the project, and retrofit any production fixes into the project landscape.
- Record each object's adaptation type (quick fix, manual, replaced, retired): testing uses it to decide depth.
What would you do?
A developer has applied a mass quick fix to 400 programs in one package in CMD. ATC now shows no errors for the package. The developer asks to release the transport to CMQ today. What should the team require first?
- Modifications: SPDD during SUM, SPAU and SPAU_ENH afterwards; transports reused in later conversions.
- Readiness findings: fix in ADT; quick fixes and mass quick fixes for known patterns.
- Re-run the S4HANA_READINESS variant locally until no in-scope errors remain.
- Change only what findings require, keep transports traceable, and record the adaptation type.
- In SPAU, reset obsolete note corrections first; check widened fields in offsets and fixed-length files.
Check your understanding · not graded
Lesson check
1. Which transaction adjusts modified dictionary objects during the SUM run?
2. Why does SAP recommend ADT rather than SE80 for adaptation?
3. What does a clean ATC run after a mass quick fix prove?
4. How does adaptation work done in CMD reach CMQ and CMP?
5. Where does SAP S/4HANA store the pricing conditions of sales documents?