SAP ECC to S/4HANA Migration: What Changes, What Stays, and What to Watch Out For

If you are planning an SAP ECC to S/4HANA migration, you already know the deadline pressure: SAP’s mainstream maintenance for ECC ends in 2027, with extended maintenance running to 2030 for organizations that pay for it. What most project teams underestimate is how different S/4HANA is at a technical level from ECC, and how that difference shapes what the migration actually requires. This post explains what changes at the architecture level, what your organization genuinely keeps, and where most projects run into serious trouble.

SAP ECC to S/4HANA migration changes the underlying data model significantly: the Universal Journal replaces separate FI and CO ledgers, Business Partner replaces the vendor/customer master split, Material Ledger becomes mandatory, and the HANA in-memory database replaces third-party DB options. Core SAP module functionality stays intact across finance, procurement, supply chain, and manufacturing. Custom ABAP code does not disappear automatically but must be remediated before go-live. The biggest risks are not technical, they are data quality issues, custom code volume, and underestimating the organizational change that comes with a new UX and restructured processes.

Table of Contents

• [What Is Actually Different in S/4HANA vs. ECC?]
• [What Does the Universal Journal Change for Finance Teams?]
• [Which Core Modules and Processes Carry Over?]
• [What Happens to Custom ABAP Code?]
• [What Are the Three Migration Approaches?]
• [What Should You Actually Watch Out For?]
• [FAQ]

What Is Actually Different in S/4HANA vs. ECC?

The most important thing to understand about S/4HANA is that it is not an upgraded version of ECC running on a faster database. It is a redesigned application with a new data model that happens to run the same core business functions. That distinction matters because it determines what kind of work the migration requires.

The database layer. S/4HANA runs exclusively on SAP HANA, an in-memory columnar database. ECC could run on Oracle, SQL Server, DB2, and other third-party databases. If your organization is running ECC on Oracle or SQL Server, the migration includes a database platform change alongside the application change. That is not a minor technical consideration.

The data model. ECC’s financial data was stored across dozens of tables. BSEG, BKPF, COEP, COBK, and others were separate structures that needed reconciliation at period close. S/4HANA consolidates this into ACDOCA, the Universal Journal table, where a single line item captures FI and CO postings simultaneously. This eliminates the reconciliation step and enables real-time profitability analysis that ECC could not support without separate reporting infrastructure.

The master data model. In ECC, customers and vendors existed as separate master records (KNA1 and LFA1 tables, respectively). S/4HANA uses the Business Partner (BP) concept as the single master record for all business relationships. Migrating to the Business Partner model requires data cleansing and structural changes to customer and vendor records. For organizations with large master data volumes or inconsistent historical data quality, this conversion work is non-trivial.

The user interface. SAP Fiori replaces much of the traditional SAP GUI for end users in S/4HANA. Fiori is a browser-based, tile-driven UX that runs on any device. The underlying transactions still exist in many cases, but SAP’s direction is Fiori-first, and new capabilities are built there. This is a meaningful change for end users and requires its own training and adoption investment.

Material Ledger. In ECC, Material Ledger was optional. In S/4HANA, it is mandatory. Organizations that were not running Material Ledger in ECC need to understand what activating it means for their inventory valuation and product costing processes before migration.

What Does the Universal Journal Change for Finance Teams?

The Universal Journal is the single biggest functional change finance teams encounter in S/4HANA, and it reshapes how month-end close works more than any other architectural decision.

In ECC, financial accounting (FI) and controlling (CO) were separate ledgers that ran in parallel. Any cost allocation or transfer pricing that crossed the boundary required a reconciliation posting. For organizations running multiple controlling areas or profit centers, this reconciliation was a consistent source of period-close delay.

S/4HANA eliminates the boundary entirely. FI and CO postings write to the same Universal Journal entry simultaneously, with a single document carrying the full account assignment detail. Real-time margin analysis (formerly CO-PA) runs directly from the Universal Journal without a data extraction step.

Finance teams that were running 8 to 12-day monthly closes in ECC can reduce that cycle meaningfully after stabilizing on S/4HANA. The reduction does not happen automatically, it requires reconfiguring close procedures to take advantage of the new architecture, but the architectural constraint forcing the delay is gone.

Which Core Modules and Processes Carry Over?

A great deal of core SAP functionality carries over from ECC to S/4HANA, which is partly why the migration timeline can feel misleading. Organizations tend to underestimate the migration work because the modules they know, MM, SD, PP, WM/EWM, PM, HR, still exist and still work recognizably. That familiarity is real. It is also not the whole story.

The core process logic in procurement, order-to-cash, plan-to-produce, and asset management is substantially preserved. Configuration built in ECC translates to S/4HANA in a brownfield conversion, though some configuration structures change. Business processes that your organization has running today will still run after migration, with modifications in some areas.

What changes within those modules is more specific:

• In MM (Materials Management), the material master retains most of its structure, but the simplified material ledger and new inventory management object model require testing even when functionality looks familiar.
• In SD (Sales and Distribution), standard order-to-cash flows are largely preserved, but output management has been redesigned (the old SAPscript/SmartForms output framework has moved toward BRF+ and the new output management approach in S/4HANA).
• In PP (Production Planning), MRP runs faster on HANA but the core planning logic is the same. However, if you are using legacy APO/SCM for advanced planning, the S/4HANA equivalent is Integrated Business Planning (IBP), which is a separate product and migration.
• In WM (Warehouse Management), SAP’s direction is Extended Warehouse Management (EWM), embedded in S/4HANA. Organizations still running classic WM will need to evaluate whether they migrate to embedded EWM during the S/4HANA project or defer it.

What Happens to Custom ABAP Code?

Custom code is where many organizations have their first honest reckoning with what S/4HANA migration actually involves.

Most large enterprises running ECC have accumulated thousands of custom ABAP objects over years or decades. Programs, function modules, user exits, BAdI implementations, and custom reports that were written against ECC’s table structures. When those table structures change (and in S/4HANA, many do), custom code that reads directly from tables like BSEG, BKPF, MARA, or vendor/customer tables may break or produce incorrect results.

SAP provides a Custom Code Migration Worklist (CCMW) and the ABAP Test Cockpit (ATC) to identify compatibility issues systematically. Every migration project should run a full custom code analysis early, not during testing. Finding 3,000 custom objects that need remediation during the testing phase is a timeline risk. Finding them during the preparation phase is a project plan input.

The good news: not all custom code needs rewriting. A significant portion of incompatibilities are resolved by redirecting table reads through SAP’s compatibility views, which map old table structures to the new data model. True rewrites are needed for code that relies on deprecated functionality or tables that have no direct mapping. The ratio varies by environment, but it is common to find that 60 to 70 percent of flagged custom objects need minor remediation rather than full replacement.

What Are the Three Migration Approaches?

Organizations choosing between migration approaches often frame this as a technical decision. It is actually a business decision with significant technical implications.

Brownfield (System Conversion) converts the existing ECC system to S/4HANA in place. Configuration, master data, historical transactional data, and most custom objects migrate. The benefit is continuity. The downside is that you carry forward everything, including technical debt, workarounds, and processes that were suboptimal before the migration. Brownfield organizations often find they have S/4HANA but are not getting its benefits because they replicated ECC’s constraints.

Greenfield (New Implementation) starts fresh. You implement S/4HANA with new configuration, clean master data, and deliberate process design. Greenfield projects take longer and cost more, but produce a cleaner system positioned to take full advantage of S/4HANA’s capabilities. Historical data typically requires an archive or data warehouse bridge rather than direct migration.

Selective Data Transition (Bluefield) is a hybrid approach. Organizations selectively migrate configuration and data from ECC while redesigning specific processes for S/4HANA’s model. More complex to plan and execute, but it lets organizations clean up problem areas without a full reimplementation.

Most large enterprises with complex ECC landscapes choose brownfield as the first step, with a plan to optimize processes in subsequent phases. The ERP implementation best practices guidance on the Resolve Tech blog covers the phasing and scoping decisions that determine whether that approach succeeds.

What Should You Actually Watch Out For?

The failure modes in SAP ECC to S/4HANA migration projects are well-documented at this point. They cluster around a few consistent patterns.

Data quality. Master data problems that were manageable in ECC become migration blockers in S/4HANA. Vendor and customer records that were never merged, material masters with conflicting data, cost center hierarchies with gaps, these surface during migration and require remediation work that was not in the original project scope. Data quality assessment should happen before sizing the project, not during execution.

Custom code volume underestimation. Organizations frequently underestimate the volume of custom code in their ECC landscape. When a formal custom code analysis has not been done, project teams often discover during preparation that the remediation workstream is 30 to 40 percent larger than planned. The analysis is not expensive to run. Skipping it is.

Integration scope. Large enterprises typically have ECC integrated with dozens of other systems: third-party logistics platforms, manufacturing execution systems, HR platforms, reporting environments. S/4HANA’s API model and interface patterns differ from ECC’s. Some integrations that worked via IDoc or RFC in ECC need to be rebuilt or updated for S/4HANA. Mapping the full integration landscape in the preparation phase prevents surprises during testing.

Organizational change management. Fiori looks and feels different from SAP GUI. Processes that worked a specific way in ECC may work differently in S/4HANA even when the underlying functionality is the same. Organizations that invest in end-user training and change management alongside the technical migration consistently have better stabilization outcomes than those that treat the go-live as the finish line.

Timeline compression. The pressure to complete the migration before 2027 or 2030 is real, but project teams that compress timelines by reducing fit-gap analysis, data quality work, or testing cycles are trading short-term schedule pressure for post-go-live stabilization problems. A migration that goes live on schedule with serious data or integration issues is more disruptive than a migration that takes an additional quarter to prepare properly.

Resolve Tech Solutions has supported SAP ECC to S/4HANA migrations for large enterprises across energy, manufacturing, and regulated industries. Our team has executed more than 800 SAP implementations, which means we have seen the failure modes above in detail and know which preparation steps prevent them. If your organization is in the planning or readiness assessment phase, the SAP assessment and advisory services page covers how we approach migration scoping. For context on the broader ERP modernization landscape, our analysis of the signs that legacy ERP is already costing organizations more than they realize covers the cost indicators that typically precede the migration decision.

FAQ

How long does an SAP ECC to S/4HANA migration take?

A brownfield conversion for a mid-size enterprise typically runs 12 to 18 months. Large enterprises with multiple SAP instances, complex integration landscapes, and high custom code volumes can run 24 to 36 months. Greenfield implementations take longer due to the extent of new configuration and process design work. Timeline is driven primarily by custom code volume, integration scope, and the quality of data preparation work.

Can SAP ECC custom code run in S/4HANA?

Some custom code runs without changes. Code that reads directly from deprecated or changed ECC tables needs remediation. SAP’s ABAP Test Cockpit identifies compatibility issues systematically. In most ECC environments, 30 to 50 percent of custom objects require some level of change, ranging from simple compatibility view adjustments to full rewrites for code that depends on removed functionality.

What is the difference between brownfield and greenfield S/4HANA migration?

Brownfield converts the existing ECC system to S/4HANA, preserving configuration, historical data, and most custom objects. Greenfield is a fresh S/4HANA implementation that does not carry forward ECC configuration or history. Brownfield is faster and preserves continuity but carries forward technical debt. Greenfield is slower and more expensive but produces a cleaner system.

Does SAP S/4HANA require HANA database?

Yes. S/4HANA runs exclusively on the SAP HANA in-memory database. Organizations running ECC on Oracle, SQL Server, or DB2 are also migrating database platforms as part of the S/4HANA project. This is a significant technical workstream and affects infrastructure sizing, database administration requirements, and cloud hosting options.

What happens to SAP ECC after the maintenance deadline?

SAP mainstream maintenance for ECC ends in 2027. Extended maintenance (with additional cost) runs to 2030. After 2030, SAP will not issue legal change packages, security patches, or support packs for ECC. Organizations still running ECC beyond 2030 will be running unsupported software with increasing security exposure and no path to regulatory compliance updates.

Schema Recommendation: FAQPage schema for the FAQ section. Article schema for the main post with author, datePublished, and organization fields.