# SAP Clean Core Extensibility Assessment > Source: https://netray.co/tools/sap-clean-core-extensibility-assessment > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A short scored assessment of how well your SAP system follows clean core principles, and what to do about the gaps. ## Category sap ## Erp SAP S/4HANA ## Audience - CIO - SAP enterprise architect - SAP program manager ## Tool **Kind:** assessment **Questions:** #### How many direct modifications of SAP standard objects exist? **Help:** Modifications are changes to SAP-delivered code, tracked in SE95 or SPAU. **Options:** ##### Many, and we do not track them **Score:** 0 ##### Dozens, tracked but not planned for removal **Score:** 1 ##### A few, with a removal plan **Score:** 2 ##### None **Score:** 3 #### How is custom code used and measured? **Options:** ##### We do not know what is used **Score:** 0 ##### We have an inventory but no usage data **Score:** 1 ##### Inventory plus usage data from SCMON or similar **Score:** 2 ##### Inventory, usage and ATC results reviewed regularly **Score:** 3 #### Which extension approach is the default for new requirements? **Options:** ##### Modify standard or copy standard programs **Score:** 0 ##### Z programs and user exits in the core **Score:** 1 ##### Released BAdIs and in-app (key user) extensibility **Score:** 2 ##### Key user extensibility and side-by-side on SAP BTP, with core kept clean **Score:** 3 #### How do custom objects access SAP data? **Options:** ##### Direct SQL on any table, including unreleased ones **Score:** 0 ##### Mostly direct table access with some function modules **Score:** 1 ##### Mix of released APIs and tables, with a policy to move to APIs **Score:** 2 ##### Released APIs and CDS views only **Score:** 3 #### How are integrations built? **Options:** ##### Point to point custom RFCs and file drops **Score:** 0 ##### Mostly IDocs and RFCs with some standard services **Score:** 1 ##### Standard APIs and events through an integration platform **Score:** 2 ##### Governed API catalog with versioning and monitoring **Score:** 3 #### How long does a support package or upgrade project take? **Options:** ##### More than six months with heavy rework **Score:** 0 ##### Three to six months **Score:** 1 ##### One to three months **Score:** 2 ##### Weeks, mostly automated regression **Score:** 3 #### Is there automated regression testing for core processes? **Options:** ##### No, all testing is manual **Score:** 0 ##### A few scripts for finance only **Score:** 1 ##### Automated tests for main order to cash and procure to pay flows **Score:** 2 ##### Broad automation run before every change **Score:** 3 #### Who governs new custom development? **Options:** ##### Anyone with developer access **Score:** 0 ##### Team lead approval only **Score:** 1 ##### Architecture review for larger items **Score:** 2 ##### Architecture board with fit-to-standard check first **Score:** 3 #### How much business logic lives in custom code compared with configuration? **Options:** ##### Most processes rely on custom code **Score:** 0 ##### Many key processes have custom logic **Score:** 1 ##### Custom code is limited to a few differentiators **Score:** 2 ##### Standard process wherever possible, custom only for clear differentiation **Score:** 3 **Bands:** #### Heavily customized core **Min:** 0 **Max:** 30 **Verdict:** The core is hard to change and upgrades will be costly. Expect large remediation effort in any S/4HANA move. **Recommendations:** - Inventory custom code and start collecting usage data now - Freeze direct modifications and new copies of standard programs - Run fit-to-standard workshops to retire custom logic #### Partly controlled **Min:** 31 **Max:** 55 **Verdict:** There is some governance, but custom code and direct table access still create upgrade risk. **Recommendations:** - Retire unused code identified by usage data - Set a policy to use released APIs for new development - Add architecture review for medium and large changes #### Mostly clean **Min:** 56 **Max:** 80 **Verdict:** The core is manageable. Focus on the remaining exceptions and on testing automation. **Recommendations:** - Remove remaining modifications on a dated plan - Expand automated regression tests - Move remaining point to point integrations to governed APIs #### Clean core practice **Min:** 81 **Max:** 100 **Verdict:** Your extensibility practice supports fast upgrades. Maintain it with governance and measurement. **Recommendations:** - Track clean core metrics each quarter - Review side-by-side extensions for cost and ownership - Keep fit-to-standard as a gate for new requests ## Content **Intro:** Clean core means keeping SAP standard code and data structures unmodified, and putting differences into governed extension layers. This assessment scores how close your landscape is. **Sections:** #### How to use the assessment **Body:** Answer each question for your main SAP production system, based on evidence rather than perception. Use SE95, SPAU, SCMON, ATC results and project records to check your answers. The score maps to four bands, each with next steps. Repeat the assessment per system if you run several, and use the result as an input to the choice between conversion and new implementation. **Bullets:** - Answer with evidence, not opinion - Involve development, Basis and business owners - Re-run every six months to track progress #### What clean core covers **Body:** The idea is to avoid modifications, use released interfaces such as APIs and CDS views, apply key user extensibility for simple fields and logic, and place larger extensions side by side on SAP BTP. The aim is that SAP can ship updates, including in RISE environments where updates are more frequent, without breaking your customizations. It is a direction rather than a binary state, and some legacy exceptions are normal. #### Reading the result and trade-offs **Body:** A low score does not mean the program should stop. It means remediation, retirement and fit-to-standard work should be sized honestly. A high score reduces conversion effort but does not remove it. Also note that clean core has costs: side-by-side extensions need ownership, integration and monitoring, and some legacy needs are cheaper to keep inside the core than to rebuild. **Cta:** If your score points to heavy remediation, Netray can help you structure the retire, keep and rewrite decisions with your team. **Faq:** #### Is clean core a SAP certification? **Answer:** No. It is a design principle promoted by SAP, not a certification. This assessment is an independent self-check, not an SAP official rating. #### Does clean core apply to on-premise S/4HANA? **Answer:** Yes, the principles apply to any deployment, though cloud editions enforce more restrictions. Following them eases later upgrades in on-premise and private cloud systems as well. #### What counts as a modification? **Answer:** A change to a SAP-delivered object, such as editing standard code or dictionary objects with a modification key. Customer-namespace objects and released enhancements are extensions, not modifications. #### Should every Z program be retired? **Answer:** No. Z programs that implement real differentiation using stable interfaces are fine. The goal is to remove unused code, modifications and fragile direct table access, not all custom work. ## Search terms sap clean core assessment, clean core extensibility, sap btp side by side extension, s4hana custom code modifications, sap clean core checklist, key user extensibility, s4hana upgrade readiness, sap rise clean core --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json