Simplification Item List and the SI Check
The simplification item list is SAP's catalog of every functional and technical change between ECC and S/4HANA, each with an identifier, documentation, and often an automated check class. The SI check runs that catalog against a specific system's custom code, configuration, and data to flag what will break during conversion. It is a mandatory gate inside Software Update Manager, not an optional readiness report.
This page covers the simplification item list as the master inventory of ECC-to-S/4HANA behavioural changes and the SI check that evaluates a given system against that inventory before and during technical conversion. It focuses on why the check blocks projects, what kind of custom code and master data issues it surfaces, and how teams misjudge its timing.
Published 16 Sept 2026· 1,166 words
Classic ECC behaviour
There is no ECC equivalent because the concept did not exist. ECC release upgrades were governed by the standard adjustment process: SPDD and SPAU compared modification-affected objects across releases, and functional changes were documented in individual release notes scattered across the help portal and in the switch framework where enhancement packages were toggled on selectively. There was no single consolidated list telling a Basis or functional team which specific tables, transactions, BAPIs or business processes had been withdrawn, redesigned, or made incompatible. Consultants relied on release notes, SAP notes gathered ad hoc, and painful discovery during regression testing. A team upgrading from ECC 6.0 EHP6 to EHP8, for example, had no automated way to ask the system 'which of my Z-programs touch a table that no longer exists in the target release'. That gap is precisely what the simplification item list was built to close, and its absence in ECC is why many architects underestimate how disruptive the equivalent check feels the first time they run it against a real S/4HANA target.
S/4HANA behaviour
The simplification item list is a structured catalog, published and maintained by SAP, of every material change introduced by the move to S/4HANA: table restructuring, transaction obsolescence, business partner consolidation, data model simplification, and process redesign. Each entry carries an identifier, a description of what changed and why, and in most cases a check class that can be executed against a live system. The SI check is the execution of that catalog against the actual system: it inspects custom code usage, active configuration, and in some cases transactional data volumes, then reports which simplification items are relevant and which are blocking. It runs at two distinct points. Early in the project it runs as part of the readiness check, producing a scoping document consultants use to plan remediation. Later, during the technical conversion itself, Software Update Manager re-executes the relevant checks as a hard gate: if a mandatory simplification item is not remediated, the conversion procedure stops and will not proceed until the underlying issue is fixed or explicitly accepted through the documented exception path. The list itself is versioned and grows as SAP adds simplification items with new S/4HANA releases, so a check run against one target release is not automatically valid against another.
Project impact
The people who feel this are Basis, ABAP development, and functional leads simultaneously, usually at different points in the timeline.
- Custom code referencing obsolete tables, deprecated BAPIs, or removed function modules fails the check and needs ATC-based remediation before the technical conversion window can be booked
- Interfaces built on transactions like the legacy customer and vendor maintenance screens are flagged because those flows are redirected under business partner consolidation, and any interface calling the old transaction codes directly needs rework
- Custom reports built directly on tables that are now compatibility views rather than physical tables can still run but with materially different performance characteristics, which shows up only under production data volume, not in a small quality-system test
- Authorization objects tied to obsolete transactions or objects need review, since roles built years earlier often still reference codes the SI check flags as withdrawn
- Project timeline risk is the biggest hit: a mandatory simplification item discovered during the technical SUM run, rather than during scoping, stops the cutover weekend cold and forces a rollback decision
- Functional consultants are pulled in to interpret business impact for items the check only flags technically, particularly around master data harmonization and process changes that the check cannot fully assess on its own
Migration actions
The SI check is not a single event; it is a recurring gate that must be treated as such from the start of the project.
- Run the readiness check early, ideally against a recent copy of the production system rather than a stale sandbox, to get an honest scope of relevant simplification items
- Triage every flagged item into mandatory pre-conversion remediation versus items that can be handled functionally after go-live, since not all flagged items block the technical procedure
- Route custom code findings through a code remediation cycle using the standard custom code check tooling, prioritizing anything the SI check marks as a hard blocker
- Address master data prerequisites separately and early, particularly anything requiring reconciliation before the conversion, since data fixes take longer than code fixes and cannot be rushed the week before cutover
- Re-run the check close to the actual conversion window, not just once at project kickoff, because the simplification item catalog itself is updated by SAP and custom code changes between scoping and cutover
- Accept that the SUM-embedded execution of the check is a hard technical gate: a mandatory item left unresolved stops the conversion procedure and there is no override path other than fixing the underlying condition
Whose problem this is
Both. Basis owns running the check and operating Software Update Manager, but interpreting what each flagged simplification item means for a specific business process, report, or interface is functional work. The project architect owns sequencing remediation against the cutover date, because technical fixes and functional decisions have different lead times and neither team can resolve a mandatory item alone.
Common pitfalls
The most common failure is treating the readiness check as a one-time deliverable produced at project kickoff and never revisited, so items introduced by custom code changes made during the project itself are missed until the technical conversion run stops on them unexpectedly.
- Teams run the check against a quality system with a small data set, pass cleanly, then hit performance or volume-related failures only during the production conversion because certain checks behave differently at scale
- Business partner-related simplification items get scoped as a technical checkbox rather than the significant data and process effort they actually are, and the underestimate surfaces during cutover rehearsal, too late to replan comfortably
- Custom code that passes the check in an early scoping run is assumed clean permanently, but ongoing development between scoping and cutover reintroduces flagged patterns that nobody re-checks
- Teams treat every flagged item as equally blocking and either over-invest in low-risk items or, worse, assume all items are advisory and get blindsided when a mandatory one halts the SUM run mid-conversion
- Exception or bypass paths for specific flagged items are pursued without understanding the downstream functional consequence, leading to a technically successful conversion with a broken business process discovered weeks later
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/simplification-item-list-and-the-si-check-in-a-conversionERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.