Key Takeaways
- Data Model is the Biggest Change: S/4HANA fundamentally simplifies the data model by replacing aggregate and index tables (e.g., COEP, MKPF) with universal tables like ACDOCA and MATDOC. Custom code relying on old tables must be rewritten.
- The Business Partner Mandate: ECC’s separate Customer (KNA1) and Vendor (LFA1) records are unified under the Business Partner (BP) framework in S/4HANA. All custom code accessing master data needs remapping to BP-compliant APIs.
- Adopt the Clean Core Principle: The long-term goal is to move custom logic out of the core and into methods like In-app extensibility (BADIs) or Side-by-Side development on SAP BTP. This ensures faster, cheaper, and safer future upgrades.
- ATC is the Essential First Step: The ABAP Test Cockpit (ATC) is mandatory for readiness. It identifies all code conflicts against the Simplification Database and guides the remediation process.
- Automation Accelerates Remediation: For large codebases, tools like Diligent Global’s Smart Code Migration Tool (SCMT) are crucial. They take ATC outputs and automate repetitive fixes, prioritize critical issues, and enforce Clean Core standards, significantly reducing migration time and manual errors.
Introduction
SAP ECC has shaped enterprise operations for decades, with custom ABAP code quietly supporting day-to-day processes from finance and logistics to planning and reporting. As SAP draws the curtain on ECC support by 2027 and shifts its roadmap fully to S/4HANA, organizations are being pulled into a new architecture that doesn’t speak the same language.
Core tables are gone, logic is restructured, and some custom transactions no longer have a place. A Z-report built years ago may now point to deprecated objects. This shift affects far more than code syntax, it touches process continuity.
Understanding where ECC and S/4HANA fundamentally diverge helps SAP teams uncover what needs to be adapted, rewritten, or reimagined to ensure readiness.
ECC to S/4HANA: Technical Differences That Affect Code Migration
S/4HANA brings fundamental changes to the underlying data model, runtime behavior, and development approach, all of which influence how custom code must be evaluated and adapted.
Following are the key technical shifts SAP teams should address during the code migration process.
- Removal of Aggregate and Index Tables
Custom reports in ECC often used tables like GLT0, COEP, or BSIS for performance. S/4HANA eliminates these in favor of real-time data access from simplified tables such as ACDOCA or MATDOC. Custom logic must adapt to this shift and recalculate totals dynamically.
- Deprecated and Replaced Tables
Tables commonly used in custom code such as, KONV, VBRP, MKPF, have been replaced or converted into compatibility views. These views support read operations only. Any write-enabled logic depending on these tables requires rework and remapping to current structures.
- Field Length Extensions
Fields like material number (MATNR) now support 40 characters. Custom validations, conversions, or interface mappings that assume an 18-character limit must be updated to prevent data loss or runtime issues.
- Discontinued Function Modules and T-Codes
Older function modules and transaction codes tied to classic credit, pricing, or logistics logic may no longer be available. Custom processes built around these will require redesign using S/4HANA-approved APIs and services.
- Shift from Batch to Real-Time Execution
S/4HANA promotes in-memory, real-time processing. Batch jobs, sequential logic, or heavy loops designed for ECC’s disk-based runtime should be optimized for HANA performance and modern data access techniques.
- Compatibility Views vs. Active Tables
Compatibility views mimic old ECC tables temporarily but do not support updates. Relying on them long term creates technical debt. Code should transition to active S/4HANA structures and whitelisted views as part of remediation planning.
Frequent Custom Code Conflicts in ECC to S/4HANA Transition
When analyzing ECC custom code for S/4HANA readiness, several patterns of incompatibility surface, often linked to technical changes in data structures, logic flow, and system behavior. These issues impact both runtime stability and long-term maintainability if left unaddressed.
Below are some of the most common compatibility issues that arise during code assessment:
- Obsolete Data Structures
Many ECC custom programs read from or write to tables that S/4HANA has either removed or restructured. COEP, MKPF, and MSEG are common examples. S/4HANA introduces universal tables like ACDOCA and MATDOC to simplify the data model. Compatibility views allow temporary read access but are not intended for long-term use. Custom code must shift to native S/4 tables or CDS views to maintain function and upgradability.
- Master Data Model Changes
ECC treated customers and vendors as distinct entities. S/4HANA unifies them under the Business Partner framework. Code that references KNA1 or LFA1 for customer/vendor master data will not update properly in S/4 unless redirected through BP APIs or tables. Migration tools can assist with mapping, but every reference in custom logic needs validation.
- Discontinued Functionality
Legacy modules like ECC Credit Management or pricing logic via KONV have been replaced. Code referencing outdated function modules or tables must adapt to S/4HANA equivalents, such as FSCM components or PRCD_ELEMENTS. These replacements often carry different data models, requiring logic redesign.
- Hard-Coded Assumptions
Over time, ECC customizations can accumulate assumptions—such as static number ranges, status codes, or fixed table references. These no longer align with S/4HANA’s real-time, simplified landscape. Custom code that bypassed standard processes or embedded workarounds should be reviewed in context of redesigned S/4 flows.
- Core Modifications and Implicit Enhancements
Modifying standard SAP code was more common in ECC. S/4HANA enforces stricter boundaries. Implicit enhancements or direct edits to dictionary objects may be ignored or deactivated in conversion. Identifying and reworking these customizations early prevents regression in critical workflows.
Adopting Clean Core for Sustainable S/4HANA Upgrades
In many ECC environments, custom logic has been built directly into the SAP core, whether through added fields, modified includes, or tightly coupled ABAP routines. These adjustments may have served a purpose at the time, but they often create friction every time the system needs to be upgraded.
S/4HANA encourages a shift in mindset. The approach now is to build around the core, not within it. SAP supports this with extension options that minimize disruption:
- In-app extensibility like BADIs, enhancement points, and CDS view extensions keep logic flexible while preserving standard behavior.
- Side-by-side development on SAP BTP enables integration via APIs, keeping custom apps fully decoupled from the core system.
- SAP Fiori-based UX brings a user-friendly, role-based interface to custom applications without relying on legacy GUI screens.
This model pays off with every system update. Clean core landscapes handle upgrades faster, with fewer issues and less time spent untangling conflicts. Instead of reapplying modifications, teams can focus on testing, validating, and improving business functionality.
Before beginning a clean core transition, it helps to assess your current custom code:
- Which developments still add business value?
- What can be retired or replaced with standard S/4HANA features?
- Where should future enhancements follow clean core design to remain stable over time?
Moving toward a clean core doesn’t mean compromising flexibility, it means gaining control over how and where innovation happens. And that foundation is what keeps the system agile as business needs evolve.
Using ABAP Test Cockpit for S/4HANA Code Readiness
Effectively managing custom code goes beyond identification; it requires thorough analysis and a clear plan for remediation. ABAP Test Cockpit (ATC) is SAP’s primary tool for this purpose, designed to run static checks across custom objects and flag any conflict with S/4HANA standards.
- ATC provides rulesets aligned with the Simplification Database, ensuring that deprecated statements, obsolete structures, or removed transaction calls are detected. Each error or warning is mapped to recommended corrections. Findings include table replacements, logic changes, and incompatible function calls.
- The tool can run locally or remotely, even from a central S/4HANA system, allowing teams to assess ECC code without full migration. This flexibility makes it easier to plan effort, delegate tasks, and identify which areas require redesign.
- Beyond initial scans, ATC also helps track unresolved issues, validate fixes through testing, and support quality gates during project reviews. Combined with unit or integration tests, it adds an extra layer of assurance that changes won’t disrupt business processes.
Used effectively, ATC becomes a lens through which all custom code is re-evaluated and made ready for the next platform.
Automating SAP Code Remediation with Diligent Global’s Smart Code Migration Tool
Upgrading to S/4HANA requires more than reviewing custom ABAP; it calls for a structured approach to apply changes accurately, and efficiently. Many SAP teams face the same challenge: hundreds or even thousands of custom objects that need remediation, each with its own dependencies and risks.
Diligent Global’s Smart Code Migration Tool (SCMT) was built for this kind of scale. It takes outputs from SAP’s ATC and translates them into guided, often automated code adjustments. The tool helps ensure changes aren’t just identified, they’re implemented cleanly, in line with S/4HANA standards and clean core principles.
Here’s where SCMT delivers its value:
- Integrated ATC Analysis: SCMT anchors its workflow on SAP’s own Test Cockpit checks. All simplification rules are applied consistently across the codebase, ensuring that nothing slips through unscanned.
- Automated Quick Fixes: Where patterns are repeatable, like deprecated table usage or function replacements, SCMT proposes or implements code corrections, reducing the risk of manual errors and accelerating resolution.
- Prioritized Issue Handling: Issues are classified into critical, major, and minor categories (P1, P2, P3), allowing teams to triage where to focus first. This prioritization supports better planning and faster delivery on essential business processes.
- Clean Core-Aligned Remediation: The tool helps steer fixes toward modern, upgrade-safe design. Developers are nudged toward CDS views, APIs, and side-by-side extensibility instead of legacy enhancements or direct core modifications.
- Full Traceability and Documentation: Each remediation is logged with before-and-after code states. SCMT builds audit-ready documentation automatically, useful for tracking, handover, or compliance needs.
- Test-Ready Output: Once updates are applied, SCMT supports validation through unit and integration test runs. This adds a layer of confidence that logic still holds after structural updates.
Getting Custom Code Ready for What’s Next
Migrating from ECC to S/4HANA brings clear technical shifts that directly impact how custom code must be handled. From simplified data models to new extension frameworks, these changes demand early analysis, clean core alignment, and smart remediation. Addressing compatibility issues up front reduces risk and sets the stage for a more stable, upgrade-ready system.
With tools like Diligent’s SCMT, SAP teams can accelerate ABAP code adaptation while improving quality and consistency. Planning ahead makes the difference between reactive fixes and a smooth transition.
Ready to see how SCMT can streamline your migration? Request a personalized demo today.
