Migration and Architecture Decision Points from ECC to S/4HANA Manufacturing
An intermediate-level walkthrough of the key architecture and migration decisions consultants face when moving manufacturing processes from ECC to S/4HANA, including data conversion, deployment model choice, and integration redesign.
Explanation
Migrating manufacturing processes from ECC to S/4HANA is not a pure technical lift; it forces a series of architecture decisions that ripple through master data, planning, and integration design. This lesson focuses on the decision points a consultant must navigate during a typical greenfield or brownfield migration project. First is the deployment model decision: on-premise, private cloud, or public cloud edition. On-premise and private cloud retain more classic configuration transactions and allow custom ABAP development, which matters for clients with heavily customized PP enhancements (custom user exits, BAdIs, or Z-programs tied to order confirmation or MRP). Public cloud editions restrict changes to released extensibility (in-app and side-by-side extensions) and standard configuration scope items, so clients with deep customization typically need significant process simplification or a private cloud/on-premise path. Consultants must assess existing custom code and Z-developments early using code inventory and simplification item analysis before committing to a target deployment model. Second is the brownfield versus greenfield decision. Brownfield (system conversion) migrates existing configuration and data with technical conversion steps, preserving history but carrying forward legacy complexity, including potentially outdated MRP settings or unused order types. Greenfield (new implementation) allows redesigning master data and processes but requires full data migration and re-testing of every process. A selective/hybrid approach exists in some cases but adds its own complexity and should not be assumed universally available for every landscape. Third, master data structures often require rework. S/4HANA's simplified data model (e.g., unified tables for goods movements and finance postings in many scenarios) means some ECC-specific structures behave differently, and certain manufacturing-related simplification items (such as changes to production order or process order underlying data structures at the technical layer) must be reviewed against the specific S/4HANA release notes rather than assumed. Consultants should verify current simplification item guidance for the specific release rather than relying on memory, since these items evolve across releases. Fourth, planning architecture must be decided: does classic MRP remain sufficient, or does the client need embedded PP/DS or IBP integration for finite capacity or network planning? This decision affects master data extensions (PP/DS-specific parameters, product/location master synchronization), interface design (for IBP, this includes planning area and master data type mapping), and cutover sequencing—PP/DS activation typically requires careful cutover planning because live orders and stock must be reconciled between classic MRP live and PP/DS optimizer scope. Fifth, integration touchpoints with MM, QM, CO, and EWM must be re-validated. Even where core logic is similar, some integration behaviors (for example, real-time stock and goods movement postings) may have different performance characteristics on S/4HANA's in-memory model, and batch jobs previously used for reconciliation may become unnecessary or need redesign. Finally, testing and rollback strategy must be defined upfront: what does a rollback look like if go-live fails, especially for a system conversion versus a new implementation, and how are cutover windows for MRP runs and open order data handled. This lesson gives consultants a checklist mindset rather than prescribing one universal migration path, since the right answer depends heavily on the client's current landscape, customization level, and target deployment model.
Real project scenario
A discrete manufacturing client on ECC 6.0 with significant custom Z-programs embedded in order confirmation logic evaluated S/4HANA public cloud but discovered during code inventory that over 40 percent of their custom enhancements had no supported extensibility equivalent. The architecture team pivoted to S/4HANA private cloud edition instead, preserving custom logic through supported clean-core-adjacent extension patterns where possible, and scheduled a phased brownfield conversion with a six-month master data cleansing project preceding technical conversion to reduce carry-forward of obsolete MRP and routing data.
Common mistakes
• Selecting public cloud edition without first completing a realistic custom code and process complexity assessment. • Assuming brownfield conversion avoids all data cleansing work, when legacy master data issues still carry forward and cause planning problems post go-live. • Underestimating cutover complexity when introducing PP/DS or IBP for the first time alongside a technical S/4HANA conversion. • Relying on outdated or remembered simplification item details instead of checking current release-specific guidance. • Failing to define a rollback and reconciliation strategy for open production orders and in-flight MRP data during cutover.
Best practices
• Perform a custom code and process complexity assessment before committing to a target deployment model. • Treat master data cleansing as a prerequisite project phase, not a cutover-weekend task. • Validate current simplification item guidance against the specific target S/4HANA release rather than relying on generic assumptions. • Plan PP/DS or IBP introduction as a distinct workstream with its own cutover and reconciliation checkpoints, especially for in-flight orders. • Define and rehearse a rollback plan before the production cutover window, including how open orders and stock will be reconciled if rollback is needed.
Interview angle
Architecture-focused interviews often ask candidates to walk through how they would decide between greenfield and brownfield, or how deployment model choice affects customization strategy. Strong candidates discuss trade-offs (cost, timeline, risk, customization retention) rather than declaring one approach universally superior, and they acknowledge that specific simplification item impacts must be verified against current release documentation rather than assumed from memory.