S/4HANA vs ECC
S/4HANA is the successor to SAP ECC, not a version upgrade. It runs only on SAP HANA, replaces the finance table landscape with the Universal Journal (ACDOCA), makes Business Partner the single customer and vendor master, moves the interface to Fiori, and removes or redirects many familiar transactions. Mainstream maintenance for ECC runs to the end of 2027, with extended maintenance available to 2030, which is why migration programmes are running now.
SAP S/4HANA vs SAP ECC at a glance
| Dimension | SAP S/4HANA | SAP ECC |
|---|---|---|
| Database | SAP HANA only | Any supported database |
| Finance data model | Universal Journal in ACDOCA, one line-item table | BSEG, BKPF, plus separate CO and asset tables |
| Aggregates and indexes | Removed; totals calculated on the fly | Totals tables such as GLT0, index tables |
| Customer and vendor master | Business Partner is mandatory | Separate KNA1 and LFA1 transactions |
| User interface | Fiori launchpad, GUI still available for many transactions | SAP GUI |
| Material number length | 40 characters | 18 characters |
| Inventory management | MATDOC | MKPF and MSEG |
| Credit management | SAP Credit Management (FSCM) | FI-AR credit management |
| Maintenance | Current strategic product | Mainstream ends 2027, extended to 2030 |
The Universal Journal is the change that matters
In ECC, finance and controlling kept separate documents that had to be reconciled. In S/4HANA both post to ACDOCA, so the reconciliation disappears and reporting happens against line items directly.
This is why period-end shortens on well-run S/4HANA projects, and why the finance team feels the change more than any other function.
What breaks in custom code
Anything that reads removed tables, relies on aggregate tables, assumes an 18-character material number, or accesses customer and vendor masters directly. SAP's readiness check and the ABAP test cockpit identify most of it.
Treat migration as the moment to retire custom code rather than convert it. Clean core discipline afterwards keeps the estate upgradable, and much of the old custom code exists only because standard functionality was missing in 2009.
Brownfield, greenfield or selective
Brownfield conversion keeps history and configuration and is fastest where the ECC estate is healthy. Greenfield re-implements on standard processes and suits estates whose configuration has drifted beyond repair. Selective data transition sits between them and is the pragmatic choice for large multi-entity landscapes.