SAP ECC vs S/4HANA: Architecture, TCO, and Migration

SAP ECC vs S/4HANA: Architecture, TCO, and Migration

SAP S/4HANA is SAP's current-generation ERP suite, built exclusively on the SAP HANA in-memory database with a simplified data model and the Fiori user interface. SAP ECC (ERP Central Component) is its predecessor — a modular ERP built on the NetWeaver platform that runs on third-party databases like Oracle, IBM DB2, and Microsoft SQL Server. The core difference is architectural: S/4HANA eliminates dozens of aggregate and index tables, merges Financial Accounting and Controlling into a single Universal Journal, and enforces a "clean core" extensibility model. If you're evaluating whether to migrate, this guide covers the technical foundations, real cost structures, migration paths, and the decisions that actually matter.

How does SAP S/4HANA's architecture differ from SAP ECC?

SAP ECC is a modular-based ERP architecture built on the SAP NetWeaver integration platform. ECC stands for ERP Central Component — the legacy ERP solution that served as the cornerstone of enterprise infrastructure before S/4HANA's introduction in 2015. Its modular design lets organizations deploy only the functional areas they need (FI, CO, MM, SD, PP, and so on) while running on their choice of relational database: Oracle, IBM DB2, Microsoft SQL Server, or SAP's own MaxDB.

SAP S/4HANA is a fundamentally different architecture. S/4HANA runs exclusively on the SAP HANA in-memory columnar database — this is not a preference but a hard technical requirement. SAP HANA stores data in RAM and processes columns rather than rows, which enables complex analytical queries to complete in seconds or milliseconds rather than the minutes or hours typical of disk-based relational databases running equivalent ECC workloads.

The practical consequence of in-memory columnar storage: S/4HANA eliminates the need for the aggregate and index tables that ECC required to make reporting tolerable on slower disk-based databases. Because HANA can compute aggregations on the fly from raw transaction data, hundreds of pre-computed summary tables become redundant and are removed from the data model.

Dimension	SAP ECC	SAP S/4HANA
Database	Oracle, DB2, SQL Server, MaxDB, HANA	SAP HANA only
Data model	Multi-table with aggregate/index tables	Simplified (ACDOCA, MATDOC, Business Partner)
User interface	SAP GUI (transaction-based)	SAP Fiori (role-based, web/mobile)
Platform	SAP NetWeaver	SAP BTP + HANA
Extensibility	Classic ABAP modifications to core	Clean core (APIs, BTP side-by-side extensions)
Analytics	Separate BW/reporting layer	Embedded real-time analytics via CDS views
Deployment options	On-premises only	On-premises, private cloud (RISE), public cloud
Release model	Enhancement Packages (EhP)	Continuous innovation via Feature Pack Stacks

The simplified data model: ACDOCA, MATDOC, and Business Partner

Universal Journal (ACDOCA)

The Universal Journal is the single biggest structural change in S/4HANA's data model. In ECC, financial and controlling data is spread across more than seven tables:

• BKPF — accounting document headers
• BSEG — accounting document line items (the largest table in most ECC systems)
• BSIS / BSAS — open and cleared G/L line items (secondary index)
• BSID / BSAD — open and cleared customer items (secondary index)
• BSIK / BSAK — open and cleared vendor items (secondary index)
• COEP / COSP / COSS — CO line items and cost object aggregates

In S/4HANA, all of these are replaced by a single table: ACDOCA — the Universal Journal. ACDOCA stores FI and CO postings in a single record, eliminating the reconciliation process that ECC required between financial accounting (FI) and controlling (CO). In ECC, periodic FI-CO reconciliation runs were standard practice; in S/4HANA, consistency between the two is automatic because the data is the same record.

The architectural implication: FI-CO reconciliation as a business process is eliminated in S/4HANA. This reduces period-end close workload but requires organizations to rethink any custom reports or processes built around ECC's separate FI and CO table structures.

Inventory Management: MATDOC

S/4HANA introduces MATDOC to replace ECC's inventory management table structure. ECC used two primary tables — MKPF (material document headers) and MSEG (material document items) — plus more than 26 supporting aggregate and index tables for stock reporting. MATDOC consolidates all of this into a single structure, eliminating the redundancy and improving stock reporting performance on HANA's columnar engine.

Business Partner consolidation

In ECC, customers and vendors are separate master data objects stored in KNA1 (customer master) and LFA1 (vendor master). S/4HANA replaces these with a unified Business Partner model, stored in BUT000, with the relationship to legacy customer and vendor IDs managed via mapping tables CVI_CUST_LINK and CVI_VEND_LINK.

This is one of the most disruptive master data changes in an ECC-to-S/4HANA migration. Any custom code, interface, or downstream system that hardcodes KNA1 or LFA1 lookups will break. Business Partner conversion is mandatory and cannot be deferred — it must be completed before go-live. Organizations with complex customer/vendor hierarchies (intercompany relationships, shared business partners across multiple roles) should allocate 6–10 weeks of dedicated master data remediation work for this conversion alone.

Material Ledger: now mandatory

In ECC, the Material Ledger was an optional module. Many organizations never activated it due to its configuration complexity. In S/4HANA, Material Ledger is mandatory — every system activates it at conversion. For organizations migrating from ECC without Material Ledger, this creates retroactive valuation decisions that aren't always scoped in initial project plans. The configuration and data preparation work for Material Ledger activation on previously non-activated systems should be explicitly included in project estimates.

SAP GUI vs SAP Fiori: the user experience shift

SAP Fiori is SAP's modern design language and the default user interface for S/4HANA. Classic SAP GUI prioritized breadth and power-user efficiency, organizing functionality through transaction codes (T-codes) and dense screen layouts optimized for keyboard navigation by trained users. Fiori takes a different approach: role-based applications designed around specific job functions, accessible via web browser and mobile devices without SAP GUI installation.

The functional difference most relevant to business users: Fiori embeds analytics directly into operational workflows. In ECC, users typically ran transactions in SAP GUI and then exported to spreadsheets or ran separate BW reports to analyze results. In S/4HANA with Fiori, dynamic tiles on a user's home screen can show — for example — how many purchase orders are overdue, and clicking that tile navigates directly to the processing transaction. This eliminates the context-switching between operational execution and analytical review.

The honest caveat: Experienced SAP GUI users frequently find specific tasks faster in the classic interface. Not all ECC transactions have equivalent Fiori apps — SAP's Fiori app library covers most common scenarios but infrequently used or highly specialized transactions may still require SAP GUI access. S/4HANA supports both interfaces simultaneously, so Fiori adoption can be gradual and role-specific rather than a hard cutover. SAP's strategic direction is unambiguous — Fiori is the primary interface going forward — but the parallel support means you're not forced to retrain all users on day one.

When does SAP ECC support end?

SAP ECC 6.0 (part of SAP Business Suite 7) reaches the end of mainstream maintenance on December 31, 2027. SAP offers optional extended maintenance through December 31, 2030, at a surcharge of 2 percentage points above the standard 22% maintenance rate (i.e., 24% of net license value annually during the extended period). SAP has publicly and repeatedly confirmed these dates are not subject to further extension.

The specifics depend on your Enhancement Package (EhP) level:

• EhP 0–5: Mainstream maintenance ended December 31, 2025. No extended maintenance option is available for these versions. Organizations still running EhP 0–5 are already in a degraded support state.
• EhP 6–8: Mainstream maintenance until December 31, 2027, with optional extended maintenance through December 31, 2030 at the 2-point surcharge.
• After 2030: SAP offers "customer-specific maintenance" — but this is a significant downgrade, not a continuation. At the same price as standard support, it delivers no new corrections, no legal/regulatory updates from SAP, and no guaranteed response times. It provides break-fix support for issues SAP already resolved before 2030, nothing more.

Market exposure as of end-2024: Only approximately 39% of SAP's 35,000 ECC customers — roughly 14,000 organizations — had purchased S/4HANA transition licenses, according to data cited by Gartner and industry analysts. License purchase indicates intent, not completion. Gartner projects more than 17,000 ECC holdouts will remain in 2027, with over 13,000 still running ECC in 2030.

Consulting market scarcity is an underappreciated deadline pressure. According to the DSAG (German-Speaking SAP User Group) Investment Report, nearly 50% of existing SAP customers plan to complete their migration by end of 2030. Organizations that start planning in 2026 or later will compete for the same pool of experienced SAP migration consultants as every organization that missed the 2027 deadline — driving rates up and availability down.

What does an SAP S/4HANA migration actually cost?

There is no single answer, but cost ranges and cost structure are well-documented across the SAP consulting market. For mid-market enterprises, total project costs commonly run $3M–$15M; for large enterprises with complex landscapes, costs exceed $50M and occasionally reach nine figures. The variance is driven primarily by custom code volume, data complexity, integration scope, and migration path chosen.

Cost categories and their realistic weights

Systems integrator (SI) fees are the largest single line item, typically representing 45–60% of total project spend in large migrations, based on benchmarks published by SAPinsider and Gartner. For a $10M migration, this means $4.5M–$6M in consulting fees alone.

Internal resource costs are the most consistently underestimated category. In large migrations, internal resource costs (employee time diverted from BAU work) account for 20–35% of total project cost when properly valued. These costs rarely appear in vendor proposals but are real — project managers, functional leads, data stewards, and finance staff contribute thousands of hours that carry opportunity cost.

Dual-run period costs are almost never included in initial budgets. Running ECC alongside S/4HANA during parallel operation and testing phases means maintaining two full system landscapes for 12–24 months — double the infrastructure, double the support effort, and double the license/maintenance costs on the ECC side during that window. For large enterprises, dual-run costs can reach $1M–$3M per year.

HANA memory sizing is a hidden cost driver specific to S/4HANA's in-memory architecture. Unlike disk-based databases where storage cost scales modestly with data volume, HANA licensing and infrastructure cost scales directly with data kept in active memory. Large historical datasets that were cheap on Oracle or DB2 become expensive on HANA. Data archiving strategy must be resolved before infrastructure contracts are signed — not after.

Custom code remediation consistently ranks among the top three technical cost drivers in S/4HANA programs, according to SAPinsider's S/4HANA Migration Benchmark Report. Organizations with 10,000+ custom ABAP objects (common in ECC landscapes with 10+ years of modifications) should budget 6–18 months of custom code analysis and remediation work.

RISE contract escalation is a long-term cost risk frequently overlooked in year-one business cases. RISE with SAP contracts typically include annual price increase provisions of 5–7%. Without negotiated caps in the initial contract, a five-year deal can cost 25–35% more in year five than year one. Model renewal pricing, not just initial year pricing.

Budget overrun reality

Approximately 40% of SAP S/4HANA migration projects exceed budget by 30% or more, based on industry surveys of SAP customers. A Rimini Street-commissioned Foundry survey of 455 SAP customers found that 95% report that building a positive ROI case for S/4HANA migration is difficult or requires significant effort. These figures don't mean migration is the wrong decision — they mean the business case requires rigorous, honest modeling rather than optimistic assumptions.

Defects found post-go-live cost 5–10x more to fix than defects caught during the testing phase, making testing budget a risk management investment rather than a discretionary line item.

Stylized TCO comparison: 500-user mid-market company, 7-year horizon

The following illustrates relative cost structure across three scenarios. Actual costs vary significantly by landscape complexity, geography, and negotiated rates — use this as a framework, not a quotation.

Cost Category	Stay on ECC (extended maint. + third-party support)	RISE with SAP (private cloud)	On-Premises S/4HANA
Software/licensing	~$2.5M (existing + extended maint. surcharge)	~$5–8M (annual subscription × 7)	~$3.5–5M (one-time license + 22% maint.)
Infrastructure	~$1.5M (existing)	Bundled in subscription	~$2–3M (own hardware/cloud)
Migration project	$0	~$4–7M	~$3–6M
Dual-run period	N/A	~$1–2M	~$0.5–1.5M
Custom code remediation	N/A	~$0.5–2M	~$0.5–1.5M
Ongoing BTP/extensions	N/A	~$0.5–1.5M	~$0.3–1M
7-year total (estimate)	~$4–6M	~$12–21M	~$10–17M

Note: Stay-on-ECC cost excludes the risk of regulatory non-compliance post-2027 and the cost of emergency response if SAP's maintenance position changes. RISE costs assume negotiated deal with infrastructure markup of 30–50% over equivalent direct-cloud hosting costs. On-premises costs assume existing internal SAP ops capability.

The on-premises perpetual model frequently shows lower cumulative TCO over seven or more years for organizations with stable, low-change ERP landscapes and existing internal SAP operations capacity. RISE delivers the most value for organizations seeking to reduce internal IT operational burden and accelerate feature adoption via SAP's managed upgrade cycle.

Brownfield vs greenfield vs bluefield: which migration path fits?

Three primary approaches exist for moving from SAP ECC to S/4HANA. The right choice depends on custom code volume, data complexity, tolerance for business disruption, appetite for process redesign, and organizational change capacity. Note that "bluefield" is a term used by SAP consulting partners and tool vendors (notably SNP Group, which trademarked the approach) — it is not an official SAP term, and you will not find it in SAP's own migration documentation, which uses "selective data transition" instead.

Brownfield (system conversion)

Brownfield migration converts the existing SAP ECC system directly to S/4HANA using SAP's Software Update Manager (SUM) with Database Migration Option (DMO). Existing configurations, data, and business processes are retained wherever compatible with S/4HANA.

Typical timeline: 12–18 months for mid-complexity landscapes; 18–24 months for large, highly customized environments.

What brownfield preserves: All existing organizational structures, custom configurations, historical transactional data, user roles, and tested business processes.

What brownfield does not fix: All custom code that references deprecated tables or APIs must still be remediated. The technical debt of the ECC landscape — unused custom objects, inconsistent master data, poorly governed configurations — carries forward. Organizations often find brownfield migrations surface problems they assumed they were avoiding.

Best fit: Organizations with stable, well-governed ECC landscapes, relatively low custom code volumes, limited appetite for process disruption, and a primary goal of reaching a supported S/4HANA platform efficiently.

Greenfield (new implementation)

Greenfield migration deploys a completely new S/4HANA environment and redesigns business processes, configurations, and organizational structures from the ground up. No ECC data or configurations are converted — everything is rebuilt on S/4HANA standards.

Typical timeline: 24–36 months for single-country implementations; 36–48+ months for global multi-entity rollouts.

What greenfield enables: Clean adoption of SAP best-practice processes, elimination of all accumulated technical debt, opportunity to rationalize organizational structures, and the cleanest possible S/4HANA foundation for future innovation.

What greenfield costs: The longest timelines, highest implementation costs, the most demanding change management programs, and significant risk of scope creep as stakeholders debate which ECC processes to replicate vs. redesign.

Best fit: Organizations undergoing operating model changes, post-merger integrations, or those whose ECC landscape has accumulated decades of customizations that have negative net value (i.e., cost more to maintain and migrate than they deliver in business benefit).

Bluefield / selective data transition

Bluefield (SAP's term: selective data transition) is a hybrid approach that creates a new S/4HANA system shell and selectively migrates data, configurations, and customizations based on business value assessment. Individual business processes, modules, and custom developments are evaluated independently — migrate as-is, redesign using standard SAP functionality, or retire entirely.

Typical timeline: 18–30 months depending on scope of selective migration decisions and number of entities involved.

What bluefield enables: Granular control over what carries forward vs. what gets redesigned. Organizations can modernize high-value processes while preserving proven ones, without the full disruption of greenfield.

What bluefield requires: Significantly more upfront analysis and governance than brownfield. The evaluation of each process and custom object for migration vs. redesign is time-consuming and requires informed business stakeholders, not just technical staff. Tooling from vendors like SNP Transformation Backbone or Natuvion is typically required to execute the selective data extraction and load.

Best fit: Complex, multi-entity landscapes where brownfield feels too restrictive (too much technical debt to carry forward) and greenfield feels too disruptive (too much proven configuration to throw away).

Factor	Brownfield	Greenfield	Bluefield / Selective
Typical timeline	12–18 months	24–48 months	18–30 months
Data carried forward	All historical data	Clean start (selective historical load)	Granular per-object decisions
Process redesign	Minimal	Complete redesign	Targeted modernization
Custom code handling	Remediate all surviving objects	Start clean	Selective retirement + remediation
Technical debt carried forward	High	None	Controlled
Change management burden	Lower	Highest	Moderate-high
Upfront analysis required	Moderate	Moderate	High
Risk profile	Lower technical risk, higher debt risk	High change mgmt risk	Moderate both
Typical fit	Stable, mature, well-governed landscapes	Operating model change, post-merger	Complex multi-entity, mixed-quality landscape
SAP official terminology	System conversion	New implementation	Selective data transition

Clean core and custom code: the hidden migration within the migration

SAP's clean core mandate requires all custom ABAP code to be removed from the S/4HANA system core in cloud deployments, replaced by extensions built through defined APIs, Business Add-Ins (BAdIs), or side-by-side applications on SAP Business Technology Platform (BTP). For on-premises S/4HANA, enforcement is softer — modifications to standard SAP objects remain technically possible — but SAP's roadmap is clear: custom code in the core will progressively limit access to new features, embedded AI capabilities, and automated upgrade processes.

Custom code remediation refers to the work required to transform legacy ABAP code so it functions reliably in the S/4HANA environment. This encompasses more than syntax fixes. Changes to S/4HANA's architecture and data model create compatibility, runtime, and performance issues for older custom code that referenced ECC-specific tables and APIs.

Common remediation categories

Table reference replacement: Custom code referencing BSEG, BSAS, BSIS, BSAD, BSID, BSAK, BSIK must be updated to use ACDOCA or its associated CDS views. Code referencing MKPF/MSEG must be updated to MATDOC. Code referencing KNA1/LFA1 must accommodate the Business Partner model.

SELECT * elimination: The SAP HANA columnar engine handles full-table-scan SELECT * statements poorly compared to row-based databases. Performance problems from this pattern are common and require rewriting queries to select only needed fields.

Deprecated function module replacement: Many ECC function modules and BAPIs are deprecated in S/4HANA. Replacements are typically released S/4HANA APIs or CDS views.

Unused object retirement: Analysis of mature ECC landscapes consistently finds that 40–60% of custom Z-objects are effectively unused — executed fewer than five times per year or never called at all. Retiring unused objects before migration reduces remediation scope substantially and is typically the highest-ROI activity in the custom code workstream.

Effort benchmarks: Custom code analysis and remediation typically runs at 50–150 ABAP objects per consultant per week depending on object complexity, required regression testing, and documentation requirements. For a landscape with 5,000 surviving custom objects (after unused object retirement), this implies 6–20 consultant-weeks of pure remediation effort, plus testing.

RISE with SAP: deployment options and commercial reality

RISE with SAP is SAP's bundled cloud transformation offering, introduced in 2021. It combines S/4HANA Cloud Private Edition (hosted on AWS, Microsoft Azure, or Google Cloud), SAP Business Network access, BTP credits, and managed Basis services into a single annual subscription contract.

S/4HANA is available across three deployment models:

On-premises: Customer owns the license (perpetual), manages infrastructure, and controls upgrade timing. Maintenance is 22% of net license value per year. Customers retain full ABAP modification capability (with the trade-offs noted above). Best TCO for organizations with strong internal SAP ops capability and stable, low-change landscapes.

Private cloud via RISE: SAP hosts on a hyperscaler of your choice, manages Basis operations, and delivers contractual SLAs for availability and upgrade cadence. Infrastructure cost is embedded in the subscription — typically representing 15–25% of total RISE annual cost, marked up 30–50% versus equivalent direct-cloud hosting, according to benchmarking by Rimini Street and independent SAP consultants. You pay for single-vendor SLA consolidation and reduced internal ops burden.

Public cloud (S/4HANA Cloud, public edition): Multi-tenant, standardized environment. Lowest configuration flexibility — organizations must conform to SAP's standard processes more completely than in private cloud or on-premises. Lowest upfront cost. Best fit for smaller organizations or subsidiaries willing to adopt SAP standard processes without modification. Note: public cloud S/4HANA has meaningful functional gaps versus private cloud in areas like manufacturing, project systems, and complex financial scenarios — evaluate these gaps specifically against your requirements before selecting this deployment.

RISE commercial specifics

RISE has no published list price. Pricing depends on: S/4HANA Cloud edition selected, Full User Equivalent (FUE) user count, BTP consumption tier, add-on modules, and hyperscaler region. Mid-sized contracts commonly run $500K–$2M per year; large enterprise contracts reach $5M–$15M+ annually. All pricing is negotiated deal-by-deal, and SAP's starting position typically leaves 15–25% negotiation room on multi-year commits.

Annual price escalation provisions of 5–7% are standard in RISE contracts. A five-year RISE deal at $2M/year with 6% annual escalation costs $11.3M in total — not $10M. Negotiate caps before signing.

RISE is not mandatory for S/4HANA adoption. On-premises S/4HANA licenses remain available, as does S/4HANA Cloud purchased outside RISE. Evaluate RISE as one option among several based on your internal IT capacity, cost structure, and appetite for vendor consolidation.

How to build a credible TCO comparison

A useful ECC-to-S/4HANA TCO model compares at least three scenarios over seven or more years: (1) stay on ECC with extended maintenance or third-party support, (2) migrate via RISE with SAP, (3) migrate to on-premises S/4HANA. Each model must include cost lines that are frequently missing from initial vendor proposals:

1. Dual-run period costs: 12–24 months of running both ECC and S/4HANA simultaneously, including infrastructure, support, and staff time.
2. HANA memory sizing impact on license cost: Model cold-data archiving and data tiering strategies before infrastructure contracts are signed. Data archiving can reduce HANA memory requirements by 30–60% in data-heavy environments.
3. BTP consumption beyond bundled credits: RISE bundles a baseline BTP credit allocation. Organizations moving significant custom code to BTP side-by-side extensions typically exceed bundled credits within 12–18 months. Budget ongoing BTP platform cost explicitly.
4. RISE renewal escalation: Model 5–7% annual increase through contract end and test whether the business case holds at year-five pricing, not year-one pricing.
5. Consulting market timing premium: The SAP consulting market was valued at approximately $16 billion in 2025, projected to approach $39 billion by 2035, according to market research cited by SAPinsider. Organizations starting migration planning in 2026 will pay materially more for experienced talent than those who started in 2023–2024.
6. Internal resource cost: Fully loaded internal staff time — project managers, functional leads, finance SMEs, data stewards — typically adds 20–35% to externally quoted project costs.
7. Regulatory exposure value: Quantify the cost of operating without SAP-delivered legal and regulatory updates post-2027. This is country- and function-specific: German payroll (DEUEV), Brazilian tax (SPED/NF-e), and DACH statutory reporting (GoBD) carry particularly high risk for organizations that depend on SAP to deliver these updates.

What about staying on ECC?

Staying on ECC past 2027 is a valid strategy in specific circumstances — but it must be a deliberate choice with a clear-eyed view of the trade-offs, not a default outcome of inaction.

What staying on ECC preserves: No migration disruption, no project spend, no dual-run costs, no change management burden.

What staying on ECC costs: No new SAP-delivered regulatory updates after mainstream maintenance ends (relevant for tax, payroll, and statutory reporting in high-change jurisdictions). No access to S/4HANA features — embedded analytics, AI-assisted processes, SAP Business Network integration. Increasing difficulty attracting ABAP developers willing to work on ECC systems as the market shifts. Higher risk of security vulnerabilities going unpatched.

Third-party support from providers like Rimini Street or Spinnaker Support can reduce annual maintenance costs (typically 50% below SAP's 22% rate) and extend the runway for ECC. The trade-off: no new SAP patches, no regulatory updates from SAP, and reliance on the third-party provider to fill compliance gaps through custom fixes. Third-party providers cover break-fix well; they do not provide SAP's full legal-change update service. Organizations in regulatory-heavy industries (financial services, pharma, public sector) should evaluate this trade-off carefully by jurisdiction.

The on-premises perpetual license model for S/4HANA often carries lower cumulative seven-year TCO than RISE for organizations with existing internal SAP operations capability and stable ERP landscapes. The honest calculation matters: SAP's RISE proposals typically do not include dual-run costs, internal resource costs, or the full cumulative impact of annual escalation. A rigorous, independently modeled TCO frequently shows a different picture than the proposal.

The data migration challenge inside S/4HANA projects

Regardless of migration path, the data migration component is where projects most often stall or exceed timeline. Master data harmonization, historical data volume decisions, and data quality cleanup consistently consume more time than project plans anticipate.

Specific recurring pain points:

Business Partner conversion breaks downstream integrations that hardcode KNA1 or LFA1 table lookups — including custom ABAP programs, middleware interfaces (SAP PI/PO or third-party iPaaS), and external systems that consume customer or vendor master data via APIs. Every integration point must be inventoried and tested before go-live. In landscapes with 50+ integrations, this is a multi-month workstream.

Material Ledger activation on ECC systems that never ran it requires retroactive valuation decisions for existing inventory — specifically, whether to value inventory at standard, moving average, or actual cost, and how to handle the opening balance. This is an accounting decision with P&L implications, not just a configuration task.

ACDOCA volume growth in multi-ledger environments surprises organizations that model HANA sizing based on ECC BSEG record counts. Multi-ledger configurations (parallel accounting under IFRS + local GAAP, for example) can generate 3–5x more ACDOCA records than equivalent ECC line items, directly increasing HANA memory requirements and cost.

Custom interface regression testing on deprecated BAPIs and function modules. Many ECC custom interfaces use BAPIs that SAP has deprecated in S/4HANA. These may not throw hard errors immediately — they may return incorrect results silently. Comprehensive regression testing of every integration, including expected output validation, is required.

Making the decision: a practical framework

The ECC-to-S/4HANA decision is a portfolio decision that balances technical debt, business strategy, regulatory exposure, vendor dependency, and financial capacity. No universal answer applies — but the following decision logic reflects how well-governed organizations approach it.

Migrate now (brownfield or bluefield) if:

• You're on EhP 6–8 and operate in jurisdictions with frequent regulatory change (German payroll, Brazilian tax, UK statutory reporting) where losing SAP's legal update service in 2027 creates material compliance risk
• Your ECC landscape is relatively clean: fewer than 5,000 active custom objects, well-governed master data, fewer than 30 external integrations
• You have confirmed budget and executive sponsorship, not just intent
• Your business needs real-time embedded analytics or SAP's AI-assisted capabilities (Joule, predictive MRP, embedded procurement analytics) within the next 3 years

Migrate later (extended maintenance window, 2025–2030) if:

• You're mid-way through another major business transformation (M&A integration, ERP carve-out, major CRM/supply chain program) and cannot absorb a concurrent S/4HANA migration
• Your custom code landscape is large and unassessed — starting without a baseline is a reliable way to miss budget and timeline
• You need 18–24 months to build internal project capacity (trained functional leads, dedicated data stewards, available technical resources)

Evaluate alternatives (third-party support, on-premises perpetual, deferred migration) if:

• Your ERP landscape is genuinely stable: low change frequency, limited regulatory exposure, mature and documented processes
• An honest seven-year TCO model with dual-run costs, internal resources, and escalation modeled does not produce a positive ROI case for migration
• You're willing to accept the trade-offs of third-party maintenance (no SAP-delivered regulatory updates, increasing talent scarcity for ECC skill set)

Whatever the path: start with assessment before commitment. Run the SAP Readiness Check to baseline your custom code landscape. Inventory every external integration. Model ACDOCA data volumes. Build the business case with real numbers — dual-run included, internal resources included, escalation modeled to year five — before choosing a timeline or signing a contract.