Material Ledger Cutover: SAP ECC to S/4HANA — Part 3: Bluefield / Selective Data Transition (SDT)

Bluefield — formally termed Selective Data Transition (SDT) — occupies the space between a full in-place system conversion and a clean-slate reimplementation. It migrates a selected subset of entities, data, and processes from one or more ECC systems into a new or partially converted S/4HANA system, while the remainder of the landscape stays in ECC during a defined coexistence period. The selectivity that makes SDT strategically attractive is also the source of its highest technical risk: data selection rules, coexistence integration, and cross-system reconciliation introduce failure modes that neither brownfield nor greenfield migrations face.

This whitepaper covers the full SDT lifecycle for Materials Management, Material Ledger (ML), and Product Costing — from entity scoping and ML activation strategy through split valuation, mixed costing, coexistence operations, and final exit. It draws directly on SAP Note 2345739 (ML migration corrections by SP level) and SAP Note 2239701 (SAP Rapid Data Migration for S/4HANA) throughout, applying each note’s guidance selectively based on whether a given entity is shell-converted or loaded via RDM.

The document closes with a definitive three-way comparison across brownfield, greenfield, and bluefield/SDT — every major technical and commercial dimension side by side — and a sign-off checklist of twenty success criteria required before any production cutover window opens.

This is Part 3 of a three-part series covering the full spectrum of SAP ECC to S/4HANA migration approaches for Material Ledger and Product Costing.

Materials Management (MM) inventory valuation, Material Ledger (ML), and Product Costing (CO-PC) — including standard costing, actual costing, COGS Split, split valuation, mixed costing, and WIP. FI open items are in scope where they interact with ML opening balances.

SDT uses a combination of tools depending on whether each entity falls under shell conversion logic or selective load logic. SAP Note 2239701 governs the RDM package (52 predefined objects, ATL job files, IDoc templates on SAP Data Services 4.3). SAP Note 2345739 governs FINS_MIG_STATUS correction notes by SP level — applicable only where shell-converted entities execute M10/M11/M20/M21. Third-party tools (SNP Bluefield, Syniti, Magnitude/Natuvion) operate in the transition layer between ECC extraction and S/4HANA load.

Brownfield converts everything. Greenfield loads everything from scratch. SDT does neither — it selects. That selectivity is the source of both SDT’s strategic value and its technical complexity.

Three structural differences define SDT:

1. Partial data scope. Not all entities, periods, or objects migrate. Decisions about what is in scope are encoded as data selection rules in the transition layer — any error in those rules produces either missing data or wrong data in S/4HANA.
2. Coexistence obligation. Because not all entities migrate simultaneously, ECC and S/4HANA run in parallel for a defined period. This requires an integration architecture, a reconciliation framework, and a governance model that neither brownfield nor greenfield requires.
3. Dual toolchain. Shell-converted entities use FINS_MIG_STATUS; selectively loaded entities use RDM. The same project may use both, for different entity subsets, simultaneously.

When a plant is selectively migrated, its ML history — CKMLPP period records, CKMLCR cost records, CKMLHD header records — either migrates with it or does not. The decision has permanent consequences:

• If ML history is not migrated: the first actual costing run in S/4HANA (CKMLCP) has no prior period data. Beginning inventory quantity is correct (loaded via RDM), but beginning actual cost is period 1 cost only. Trend analysis and CKM3N drillback into pre-migration periods are unavailable.
• If ML history is migrated: the transition layer must filter CKMLPP/CKMLCR records by plant and fiscal year with precision. An incorrect filter that includes records from non-migrated plants contaminates the S/4HANA ML ledger.

There is no retroactive correction for ML history gaps after go-live. The decision must be made, documented, and validated before data extraction begins.

A shell conversion creates a technical S/4HANA system by running SUM on a copy of the ECC production system, then selectively deleting or retaining data. The result is a fully converted S/4HANA system with an S/4HANA-native data model (ACDOCA, Universal Journal), but with a controlled subset of business data. FINS_MIG_STATUS M10/M11/M20/M21 executes on this shell system for the retained entities. Entities whose data is deleted from the shell and reloaded via RDM follow greenfield rules.

| Selectivity Type | Example | ML Impact | |---|---|---|---| | Company code carve-out | CC 1000 migrated; CC 2000 stays in ECC | All plants in CC 1000 migrate; ML type, currency types, and PC valuation scoped to CC 1000 | | Plant-level selectivity | Plants 0001–0005 migrate; Plants 0006–0010 stay | Valuation area = plant; each plant’s ML records are independently scopeable | | Material-level selectivity | Only finished goods migrate; raw materials stay | Dangerous — ML documents reference materials across categories; cross-material actual cost rollup breaks | | Fiscal year selectivity | Only current FY migrates; prior years left in ECC | ML history gap for all periods before cutover FY; CKM3N limited to cutover period onward |

Object-level selectivity below plant level is not recommended for ML. The ML document structure (CKMLHD → CKMLCR → CKMLPP) is plant-cohesive — splitting it within a plant creates irreconcilable gaps.

In S/4HANA, ML is mandatory and activated at valuation area level (= plant in standard configuration). In SDT:

• Migrated plants are activated in S/4HANA from day one.
• Non-migrated plants remain active in ECC.
• If a company code spans both migrated and non-migrated plants, the company code exists in both systems during coexistence — with different plant sets in each.
• ML type (OMXW) must be configured consistently for all plants in the same company code, even if those plants are in different systems during coexistence.

RISE with SAP targets S/4HANA Cloud Private Edition (PCE). PCE is S/4HANA on managed cloud infrastructure with SAP operating the basis layer. ML behavior in PCE is functionally identical to on-premise S/4HANA. SDT-specific considerations for RISE:

• Data volume constraints: PCE sizing is contracted. Large ML history migrations may require volume negotiation.
• Transport management: configuration changes (ML type, currency types) must go through SAP’s managed transport landscape — lead times for configuration activation are longer than on-premise.
• Network connectivity for coexistence integration: ALE/IDoc between ECC (on-premise) and PCE (cloud) requires a secure network path — typically SAP Integration Suite as middleware.
• NZDT: SAP Downtime Minimization Service is available for PCE conversions but requires SAP engagement; self-service NZDT is not available in PCE.

These tools operate in the transition layer (Zone 2). They do not replace FINS_MIG_STATUS or RDM; they augment them with selectivity logic that SAP-native tools do not provide natively.

When only a subset of valuation types is migrated:

• The valuation category (OMWC configuration) must be present in S/4HANA for all types, even those with zero stock.
• The MBEW record for each valuation type must be created in S/4HANA at cutover, regardless of whether it carries opening stock.
• Any valuation type remaining in ECC during coexistence must have its inventory excluded from S/4HANA opening balances — double-counting risk is high.
• Zero-stock valuation type records must still be created via Job_DM_InventoryBalance with zero quantity and zero value.

If procurement alternative A references a sending plant still in ECC and not yet migrated, the cost rollup for that alternative is unavailable in S/4HANA at cutover. Resolution options: (a) exclude the cross-system alternative and document the variance; (b) hard-code the ECC-side cost as a manual price; (c) delay migration of the receiving plant until the sending plant is also migrated. Option (c) is lowest risk.

In SDT scenarios where migrated and non-migrated entities share the same chart of accounts, the GL account determination logic (OBYC) must be consistent between ECC and S/4HANA. Any OBYC change in S/4HANA not replicated to ECC creates cross-system posting mismatches. Valuation class changes during coexistence are extremely high risk.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    subgraph Z1["Zone 1 — ECC Retained"]
        ECC_MM["MM / Inventory<br>(non-migrated plants)"]
        ECC_ML["ML / CKMLHD / CKMLPP<br>(non-migrated entities)"]
        ECC_FI["FI / CO Documents<br>(non-migrated CCs)"]
        ECC_MD["Material Master / MBEW<br>(shared master data)"]
    end

    subgraph Z2["Zone 2 — Transition Layer"]
        SEL["Data Selection Rules<br>(entity / plant / FY filters)"]
        EXT["Extraction Engine<br>(SNP Bluefield / Syniti)"]
        XFORM["Transformation Logic<br>(field mapping / value mapping)"]
        RDM_JOB["RDM ATL Jobs<br>(SAP DS 4.3)"]
        FINS_MIG["FINS_MIG_STATUS<br>(shell-converted only)"]
        STAGE["Migration Cockpit<br>Staging Area"]
        ALE["ALE / IDoc<br>Master Data Sync"]
        CPI["SAP Integration Suite<br>(coexistence transactions)"]
    end

    subgraph Z3["Zone 3 — S/4HANA Target"]
        S4_ACDOCA["ACDOCA<br>Universal Journal"]
        S4_ML["CKMLHD / CKMLCR / CKMLPP<br>(migrated plants)"]
        S4_MBEW["MBEW / Material Valuation<br>(migrated plants)"]
        S4_CKM3N["CKM3N / ML Reports"]
        S4_PC["Product Costing<br>Standard + Actual"]
    end

    ECC_MD -->|"master data extracted"| SEL
    ECC_ML -->|"ML records extracted"| SEL
    ECC_MM -->|"inventory balances extracted"| SEL
    ECC_FI -->|"FI balances extracted"| SEL

    SEL --> EXT
    EXT --> XFORM
    XFORM --> RDM_JOB
    XFORM --> FINS_MIG
    RDM_JOB --> STAGE
    FINS_MIG --> S4_ML
    STAGE --> S4_ACDOCA
    STAGE --> S4_MBEW
    STAGE --> S4_ML

    ECC_MD -->|"ongoing sync"| ALE
    ALE --> S4_MBEW
    ECC_FI -->|"cross-system transactions"| CPI
    CPI --> S4_ACDOCA

    S4_ACDOCA --> S4_CKM3N
    S4_ML --> S4_CKM3N
    S4_MBEW --> S4_PC

    class ECC_MM,ECC_ML,ECC_FI,ECC_MD source
    class SEL,EXT,XFORM,RDM_JOB,FINS_MIG,STAGE,ALE,CPI integration
    class S4_ACDOCA,S4_ML,S4_MBEW,S4_PC target
    class S4_CKM3N reporting

During coexistence, the following integration points are mandatory:

• ALE distribution model: MATMAS, CREMAS, DEBMAS IDocs. Any valuation-class-relevant field change in ECC must trigger immediate replication to S/4HANA.
• SAP Integration Suite: For cross-system goods movements (STO between ECC plant and S/4HANA plant), middleware must generate mirror postings in both systems.
• Cross-system ML document reconciliation: No SAP-native tool performs this automatically. A custom reconciliation report comparing ECC CKMLPP and S/4HANA CKMLPP by material/plant/period must be built and run monthly.
• G/L balance reconciliation: ECC FBL3N / MB5L vs. S/4HANA FAGLB03 / Universal Journal — run monthly minimum; weekly during first quarter of coexistence.

flowchart TD
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000

    START["SDT Entity — Determine Migration Method"]

    START --> Q1{"Is this entity migrated via<br>shell conversion (SUM on ECC copy)?"}

    Q1 -->|Yes| SHELL["Shell-Converted Entity"]
    Q1 -->|No| SELECTIVE["Selectively Loaded Entity"]

    SHELL --> FINS["Use FINS_MIG_STATUS<br>M10 → M11 → M20 → M21<br>(brownfield rules apply)"]
    SHELL --> NOTES["Apply all relevant notes<br>from SAP Note 2345739<br>per S/4HANA version + SP"]

    SELECTIVE --> RDM_PATH["Use RDM<br>Job_DM_MaterialMaster<br>Job_DM_InventoryBalance"]
    SELECTIVE --> NO_FINS["FINS_MIG_STATUS<br>does NOT run<br>(greenfield rules apply)"]
    SELECTIVE --> RDM_NOTES["Apply SAP Note 2239701<br>RDM object list and constraints"]

    FINS --> VALIDATE["ML Activation Check<br>FINS_MIG_STATUS M21"]
    RDM_PATH --> VALIDATE

    VALIDATE --> GOLIVE["Go-Live: Entity Active in S/4HANA"]

    class START,Q1 integration
    class SHELL,SELECTIVE source
    class FINS,RDM_PATH,VALIDATE,GOLIVE target
    class NOTES,NO_FINS,RDM_NOTES integration

Data selection rules are the central control mechanism of any SDT. For ML, selection rules must operate on:

• Company code (BUKRS): Primary entity boundary
• Plant / Valuation area (WERKS / BWKEY): ML is plant-cohesive; plant is the minimum selection unit for ML
• Fiscal year (GJAHR): Controls which CKMLPP period records are extracted
• Material type (MTART): Use with caution — material-level selectivity within a plant breaks ML document integrity
• Special stock (SOBKZ): Consignment, project stock, and sales order stock must be explicitly included or excluded

Selection rules must be version-controlled, peer-reviewed, and tested in mock cutovers before production use.

flowchart LR
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    subgraph SRC["ECC Source Systems"]
        ECC1["ECC Production<br>(all entities)"]
        ECC_DB["ECC Database<br>CKMLPP / MBEW / FI"]
    end

    subgraph TRANS["Transition Layer — Zone 2"]
        SNP["SNP Bluefield<br>Selective Extraction"]
        SYN["Syniti<br>Transformation Engine"]
        DS["SAP Data Services 4.3<br>RDM ATL Jobs"]
        STAGE2["Migration Cockpit<br>Staging Tables"]
        FINS2["FINS_MIG_STATUS<br>(shell entities)"]
        INFOSTEW["SAP Information Steward<br>Data Quality Validation"]
    end

    subgraph TGT["S/4HANA Target — Zone 3"]
        S4_MM["MM / Inventory<br>(migrated plants)"]
        S4_ML2["Material Ledger<br>CKMLHD / CKMLPR"]
        S4_FI["ACDOCA<br>Universal Journal"]
        S4_CO["CO-PC<br>Product Costing"]
    end

    subgraph REP["Reporting"]
        WEBI["WebI Reconciliation<br>Reports (Note 2239701)"]
        CKM3N2["CKM3N<br>ML Analysis"]
    end

    ECC1 --> SNP
    ECC_DB --> SNP
    SNP --> SYN
    SYN --> DS
    DS --> STAGE2
    DS --> INFOSTEW
    STAGE2 --> S4_MM
    STAGE2 --> S4_FI
    ECC_DB --> FINS2
    FINS2 --> S4_ML2
    S4_MM --> S4_CO
    S4_ML2 --> S4_CO
    S4_FI --> WEBI
    S4_ML2 --> CKM3N2

    class ECC1,ECC_DB source
    class SNP,SYN,DS,STAGE2,FINS2,INFOSTEW integration
    class S4_MM,S4_ML2,S4_FI,S4_CO target
    class WEBI,CKM3N2 reporting

SAP Note 2345739 contains correction notes for FINS_MIG_STATUS M10/M11/M20/M21 across S/4HANA 2021 (SP00–08), 2022 (SP00–08), 2023 (SP00–08), and 2025 (SP00–02). In SDT, applicability is determined entity by entity.

NZDT is disproportionately important in SDT because the migrated entity subset may represent only a portion of total business volume — business continuity during cutover is a hard requirement. All NZDT-flagged notes in SAP Note 2345739 must be implemented before the first mock cutover.

1. Identify your S/4HANA target version (2021, 2022, 2023, or 2025).
2. Identify your installed SP level.
3. For each note marked X in your SP column: the correction is not yet in the SP and must be manually implemented.
4. Apply this logic only for shell-converted entities. For RDM-loaded entities, skip the entire FINS_MIG_STATUS note set.
5. Implement Note 2416066 (resettable steps) universally.
6. Implement Note 2385542 (EKBZ integrity) universally.

SAP Note 2239701 governs the SAP Rapid Data Migration (RDM) package: SAP Data Services 4.3 ATL files, IDoc mapping templates, Migration Services Tool, and WebI reconciliation reports. In SDT, RDM is the primary load mechanism for selectively migrated entities.

For any entity that is not shell-converted, RDM handles all object loading. The 52-object list in SAP Note 2239701 applies in full, but selectivity rules are applied at the source file / ATL job level — not within the RDM package itself. The RDM package has no native entity-filter mechanism; all selectivity is implemented upstream.

SAP Note 2239701 explicitly warns: “There are risks when using INFREC to migrate data. The IDoc type INFREC is meant for info record distribution via ALE, not for data transfer.” Purchase info records must be loaded via the supported API path (ME_INFORECORD_MAINTAIN or BAPI equivalent), not via INFREC IDoc.

BP records are enterprise-wide in S/4HANA — not scoped to a single company code or plant. In SDT carve-out scenarios, a BP may represent a customer or vendor that transacts with both migrated and non-migrated entities. The resolution: use ALE/IDoc (DEBMAS, CREMAS, ADRMAS) to maintain ECC customer/vendor master as master of record during coexistence. S/4HANA BP is updated via inbound IDoc on any ECC change. Do not allow BP changes to originate in S/4HANA during coexistence unless the change replicates back to ECC.

CO allocation cycles that span migrated and non-migrated plants must be split: the portion within migrated plants runs in S/4HANA; the portion in non-migrated plants runs in ECC. Cross-system allocation is not supported natively — either re-route the allocation to keep it within one system, or post a manual journal entry in the receiving system based on the sending system’s result.

SAP Note 2239701 is explicit: “We do not provide any support for custom SAP Data Services code.” In SDT, custom DS flows are almost always required for selectivity logic. All custom DS flows must be independently validated against ECC source data before mock cutover 1.

SAP Note 2239701 includes SAP Information Steward content for de-duplication of Customer, Vendor, and Business Partner. In SDT carve-out scenarios where source data may exist in multiple ECC systems, de-duplication before load is essential to prevent duplicate BP records in S/4HANA.

In S/4HANA, ML is mandatory at plant level. The activation sequence in SDT:

1. ML type (OMXW) configured for all migrated plants before any data load.
2. Currency types assigned to ML type — must include all currency types active in ECC for those plants.
3. Actual costing activation per plant (if applicable) — irreversible decision.
4. Data load (RDM or FINS_MIG_STATUS).
5. ML activation check (FINS_MIG_STATUS M21 for shell entities; manual consistency check for RDM-loaded entities).

All plants within the same company code must share the same ML type. In SDT where a company code spans migrated and non-migrated plants, the ML type configured in S/4HANA for the migrated plants is the ML type that will apply to all plants in that company code when they eventually migrate. Changing the ML type after any data has been loaded is not supported.

Currency types cannot be added to an ML type after inventory data has been posted. Validate all currency type requirements against ECC CKMLMV configuration before ML type build.

During coexistence, monthly reconciliation must: (1) extract CKMLPP balances by plant from ECC (non-migrated plants); (2) extract CKMLPP balances by plant from S/4HANA (migrated plants); (3) compare aggregate balances at company code level against G/L inventory accounts in both systems; (4) investigate and resolve any difference before period-end close in either system.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    subgraph ECC_ZONE["ECC — Retained Plants"]
        EP1["Plant 0006<br>ML Active in ECC"]
        EP2["Plant 0007<br>ML Active in ECC"]
        EP3["Plant 0008<br>ML Active in ECC"]
        ECC_CLOSE["ECC Period-End Close<br>CKMLCP runs for 0006-0008"]
    end

    subgraph SDT_ZONE["Transition — Cutover Window"]
        MLTYPE["ML Type Configuration<br>OMXW — all migrated plants"]
        CURR["Currency Type Assignment<br>10 / 30 / 31 / 32"]
        ACT_COST["Actual Costing Activation<br>per plant — irreversible"]
        DATA_LOAD["Data Load<br>RDM or FINS_MIG_STATUS"]
        ACT_CHECK["ML Activation Check<br>M21 or manual validation"]
    end

    subgraph S4_ZONE["S/4HANA — Migrated Plants"]
        SP1["Plant 0001<br>ML Active in S/4HANA"]
        SP2["Plant 0002<br>ML Active in S/4HANA"]
        SP3["Plant 0003<br>ML Active in S/4HANA"]
        S4_CLOSE["S/4HANA Period-End Close<br>CKMLCP runs for 0001-0003"]
    end

    subgraph RECON["Coexistence Reconciliation"]
        RECON_RPT["Monthly ML Balance<br>Reconciliation Report"]
        GL_RECON["G/L Balance Comparison<br>ECC vs S/4HANA"]
    end

    MLTYPE --> CURR
    CURR --> ACT_COST
    ACT_COST --> DATA_LOAD
    DATA_LOAD --> ACT_CHECK
    ACT_CHECK --> SP1
    ACT_CHECK --> SP2
    ACT_CHECK --> SP3

    EP1 --> ECC_CLOSE
    EP2 --> ECC_CLOSE
    EP3 --> ECC_CLOSE

    ECC_CLOSE --> RECON_RPT
    S4_CLOSE --> RECON_RPT
    RECON_RPT --> GL_RECON

    class EP1,EP2,EP3,ECC_CLOSE source
    class MLTYPE,CURR,ACT_COST,DATA_LOAD,ACT_CHECK integration
    class SP1,SP2,SP3,S4_CLOSE target
    class RECON_RPT,GL_RECON reporting

Split valuation creates separate MBEW records for each valuation type under a valuation category. Rules for SDT:

• All valuation types for a given material/plant combination must be migrated in the same cutover window.
• Zero-stock valuation types must be created in S/4HANA even if they carry no opening inventory.
• The valuation category configuration (OMWC) must be identical in both ECC and S/4HANA during coexistence.

1. Maintain a split valuation type registry: for each material/plant with split valuation, document which types are in ECC and which are in S/4HANA.
2. Run MB52 (ECC) and equivalent S/4HANA inventory report monthly for all split-valuation materials. Compare to G/L inventory account balances in both systems.
3. Any difference greater than defined materiality threshold triggers a freeze on goods movements for that material.
4. Do not allow valuation class changes (BKLAS) for any split-valuation material during coexistence.

OMWC must be synchronized between ECC and S/4HANA throughout coexistence. Establish a configuration change freeze for OMWC in both systems from cutover day 1. Any required OMWC change requires approval from both the ECC functional owner and the S/4HANA functional owner.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    subgraph PREP["Pre-Cutover Preparation"]
        SV_INV["Inventory Split Valuation Types<br>by material / plant"]
        OMWC_CHECK["OMWC Configuration Check<br>ECC vs S/4HANA alignment"]
        SV_DECISION["Decision: Migrate all types<br>in same window?"]
    end

    subgraph EXTRACT["Extraction — Zone 2"]
        SV_EXTRACT["Extract all MBEW records<br>per valuation type"]
        ZERO_CHECK["Identify zero-stock<br>valuation types"]
        SV_VALIDATE["Validate completeness:<br>all types accounted for"]
    end

    subgraph LOAD["Load — Zone 3"]
        SV_HEADER["Create valuation category<br>header record in S/4HANA"]
        SV_TYPES["Load all valuation type<br>MBEW records via RDM"]
        ZERO_LOAD["Load zero-stock types<br>with zero qty / zero value"]
        SV_ACTIVATE["ML activation check<br>per valuation type"]
    end

    subgraph COEX["Coexistence Controls"]
        SV_REGISTRY["Maintain split valuation<br>type registry"]
        SV_RECON["Monthly reconciliation:<br>MB52 ECC vs S/4HANA"]
        OMWC_FREEZE["OMWC configuration<br>freeze — both systems"]
    end

    SV_INV --> OMWC_CHECK
    OMWC_CHECK --> SV_DECISION
    SV_DECISION -->|"All types migrate together"| SV_EXTRACT
    SV_DECISION -->|"Partial migration required"| RISK_FLAG["Document risk;<br>obtain sign-off"]
    RISK_FLAG --> SV_EXTRACT

    SV_EXTRACT --> ZERO_CHECK
    ZERO_CHECK --> SV_VALIDATE
    SV_VALIDATE --> SV_HEADER
    SV_HEADER --> SV_TYPES
    SV_TYPES --> ZERO_LOAD
    ZERO_LOAD --> SV_ACTIVATE

    SV_ACTIVATE --> SV_REGISTRY
    SV_REGISTRY --> SV_RECON
    SV_RECON --> OMWC_FREEZE

    class SV_INV,SV_EXTRACT,ZERO_CHECK source
    class OMWC_CHECK,SV_DECISION,SV_VALIDATE,RISK_FLAG,SV_REGISTRY,SV_RECON,OMWC_FREEZE integration
    class SV_HEADER,SV_TYPES,ZERO_LOAD,SV_ACTIVATE target

If procurement alternative A is produced in a migrated plant (S/4HANA) and alternative B in a non-migrated plant (ECC), the S/4HANA cost estimate cannot reference the ECC plant’s cost data directly.

Transaction OMX1 must be identical for all plants in the same controlling area, regardless of which system they are in. If migrated plants use multilevel actual costing (OMX1 = 3) and non-migrated plants use single-level (OMX1 = 2), period-end actual costing results are not comparable across systems. Align OMX1 before any data load.

Standard cost estimates (CK11N / CK40N) released in S/4HANA must reference only BOM and routing components that exist in S/4HANA at release time. Either: (a) load all component material masters into S/4HANA before cost estimate release; or (b) use a planned price for ECC-side components until those plants migrate. Option (a) is strongly preferred.

CKMLCP in S/4HANA during coexistence runs only for migrated plants. CKMLCP in ECC runs only for non-migrated plants. No cross-system actual cost rollup is possible. This is a permanent gap for the coexistence period — it resolves only when all plants in the same actual costing run scope are in the same system.

If procurement alternatives are split across ECC and S/4HANA, re-weight the S/4HANA mixed costing configuration to reflect only in-scope alternatives during coexistence. Document the weighting adjustment and its financial impact. Restore full weighting when all alternatives are in S/4HANA.

Coexistence period actual costing run cannot span ECC and S/4HANA plants in the same run. Period-end close sequence: (1) ECC CKMLCP for non-migrated plants; (2) S/4HANA CKMLCP for migrated plants. The two runs are independent. Actual costing activation per plant in S/4HANA is irreversible — confirm for every migrated plant before data load.

COGS Split must be activated for all migrated plants before the first goods issue in S/4HANA. If activated after the first goods issue, historical goods issue documents cannot be retroactively split — a permanent reporting gap. For shell-converted entities, verify COGS Split was active in ECC; if so, it carries through the shell conversion automatically.

Rule: No open production order should cross the ECC/S/4HANA boundary at cutover.

Currency type 32 (profit center valuation) must be configured in the ML type for all migrated plants before any data load. Cannot be added post-load. Validate against ECC CKMLMV and PCA configuration before ML type build.

In SDT coexistence, if entity A is in S/4HANA and entity B is in ECC, intercompany transactions require: a transfer pricing document in the sending system; a mirror posting in the receiving system via integration middleware; ML documents in each system reflecting the correct transfer price. No native cross-system transfer pricing reconciliation tool exists — a custom reconciliation report is required.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    subgraph ECC_SYS["ECC — Non-Migrated Entities"]
        ECC_MAT["Material Master<br>(master of record)"]
        ECC_VEND["Vendor / Customer<br>(master of record)"]
        ECC_INV["Inventory / ML<br>(non-migrated plants)"]
        ECC_FI2["FI / CO Documents<br>(non-migrated CCs)"]
        ECC_PROD["Production Orders<br>(non-migrated plants)"]
    end

    subgraph MIDDLEWARE["Integration Middleware"]
        ALE2["ALE / IDoc Distribution<br>MATMAS / CREMAS / DEBMAS"]
        CPI2["SAP Integration Suite<br>Transactional Middleware"]
        STO_INT["STO Integration<br>Cross-system stock transfers"]
        IC_INT["Intercompany Integration<br>TP postings / invoices"]
    end

    subgraph S4_SYS["S/4HANA — Migrated Entities"]
        S4_MAT["Material Master<br>(replicated from ECC)"]
        S4_VEND["Business Partner<br>(replicated from ECC)"]
        S4_INV2["Inventory / ML<br>(migrated plants)"]
        S4_FI2["ACDOCA<br>(migrated CCs)"]
        S4_PROD["Production Orders<br>(migrated plants)"]
    end

    subgraph RECON2["Reconciliation Layer"]
        RECON_ML["ML Balance<br>Reconciliation Report"]
        RECON_GL["G/L Balance<br>Reconciliation Report"]
        RECON_INV["Inventory Quantity<br>Reconciliation Report"]
    end

    ECC_MAT -->|"MATMAS IDoc"| ALE2
    ECC_VEND -->|"CREMAS / DEBMAS IDoc"| ALE2
    ALE2 --> S4_MAT
    ALE2 --> S4_VEND

    ECC_INV -->|"STO cross-system"| STO_INT
    STO_INT --> S4_INV2

    ECC_FI2 -->|"Intercompany postings"| IC_INT
    IC_INT --> S4_FI2

    ECC_PROD -->|"Cross-system order data"| CPI2
    CPI2 --> S4_PROD

    ECC_INV --> RECON_ML
    S4_INV2 --> RECON_ML
    ECC_FI2 --> RECON_GL
    S4_FI2 --> RECON_GL
    ECC_INV --> RECON_INV
    S4_INV2 --> RECON_INV

    class ECC_MAT,ECC_VEND,ECC_INV,ECC_FI2,ECC_PROD source
    class ALE2,CPI2,STO_INT,IC_INT integration
    class S4_MAT,S4_VEND,S4_INV2,S4_FI2,S4_PROD target
    class RECON_ML,RECON_GL,RECON_INV reporting

Valuation class change protocol during coexistence: (1) Change request raised in ECC; (2) impact assessment — does this material exist in migrated S/4HANA plants?; (3) if yes, coordinate simultaneous change in both systems within the same posting period. A valuation class change in ECC not replicated to S/4HANA within the same period will cause G/L account determination errors at the next goods movement in S/4HANA.

Cross-system STOs require: a purchase order in the receiving system; an outbound delivery in the supplying system; an inbound goods receipt in the receiving system. The integration middleware must generate the goods issue posting in the supplying system and trigger the goods receipt in the receiving system without double-counting. ML documents are generated independently in each system and must be reconciled manually by matching the STO number across systems.

Recommended maximum coexistence period is 12 months. Beyond 12 months, reconciliation complexity grows non-linearly, master data governance fatigue sets in, and regulatory/audit risk increases as financial statements span two systems with different data models. If the coexistence period must exceed 12 months, a formal extension risk assessment must be conducted and approved at CFO/CIO level.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100,color:#000
    classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
    classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

    P1["Phase 1: Assess and Scope<br>10–16 weeks"]
    P2["Phase 2: Configure and Build<br>6–10 weeks"]
    P3["Phase 3: Data Selection<br>and Extraction<br>4–8 weeks"]
    P4["Phase 4: Mock Cutovers<br>and Coexistence Testing<br>3–5 weeks"]
    P5["Phase 5: Cutover Execution<br>Migration Window"]
    P6["Phase 6: Coexistence Operations<br>Variable — max 12 months"]
    P7["Phase 7: Final Cutover<br>and Hypercare"]

    P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7

    subgraph PHASE1["Phase 1 Key Outputs"]
        E1A["Entity scope document"]
        E1B["Data selection rule specs"]
        E1C["Coexistence architecture"]
        E1D["Note 2345739 implementation log"]
    end

    subgraph PHASE2["Phase 2 Key Outputs"]
        E2A["ML type + currency config"]
        E2B["ALE distribution model"]
        E2C["Integration Suite flows"]
        E2D["RDM ATL jobs configured"]
    end

    subgraph PHASE3["Phase 3 Key Outputs"]
        E3A["Extracted ML dataset"]
        E3B["EKBZ validation report"]
        E3C["RDM source files"]
        E3D["Data freeze confirmation"]
    end

    subgraph PHASE4["Phase 4 Key Outputs"]
        E4A["Mock cutover 1 + 2 logs"]
        E4B["Coexistence test report"]
        E4C["Business sign-off"]
    end

    subgraph PHASE5["Phase 5 Key Outputs"]
        E5A["M10/M11/M20/M21 complete"]
        E5B["RDM inventory balance loaded"]
        E5C["Go/no-go checkpoint passed"]
        E5D["S/4HANA open for business"]
    end

    subgraph PHASE6["Phase 6 Key Outputs"]
        E6A["Monthly reconciliation reports"]
        E6B["ALE error queue at zero"]
        E6C["Coexistence exit criteria met"]
    end

    subgraph PHASE7["Phase 7 Key Outputs"]
        E7A["Final entity migration complete"]
        E7B["ECC decommissioned"]
        E7C["First unified period-end close"]
        E7D["Steady-state handoff"]
    end

    P1 --- PHASE1
    P2 --- PHASE2
    P3 --- PHASE3
    P4 --- PHASE4
    P5 --- PHASE5
    P6 --- PHASE6
    P7 --- PHASE7

    class P1,P2,P3 source
    class P4,P5 integration
    class P6,P7 target
    class PHASE1,PHASE2,PHASE3,PHASE4,PHASE5,PHASE6,PHASE7 reporting

Period-end close sequence during coexistence is non-negotiable:

1. ECC period-end close first: Execute CKMLCP for all non-migrated plants in ECC. Confirm completion and post period-end ML documents. Close ECC posting period for inventory.
2. S/4HANA period-end close second: Execute CKMLCP for all migrated plants in S/4HANA. The S/4HANA run must not begin until ECC CKMLCP is confirmed complete.
3. Cross-system reconciliation: After both runs complete, execute cross-system ML balance reconciliation. Investigate and resolve any difference before financial statements are closed.
4. Financial statement close: Only after reconciliation is signed off by Finance Controller.

If ECC CKMLCP fails or is delayed, the S/4HANA CKMLCP must also be delayed. There is no workaround for this sequencing dependency during coexistence.

1. Define and version-control all data selection rules before extraction begins. Data selection rules are the single point of highest failure risk in SDT. A wrong fiscal year filter, a missing plant, or an incorrect company code boundary migrates the wrong data or leaves required data behind. Every selection rule must be peer-reviewed, documented in version control, and validated against ECC record counts before production extraction runs. No exceptions.

2. Implement SAP Note 2416066 (resettable steps) before the first mock cutover — for all entities. SDT migrations restart more frequently than brownfield or greenfield migrations because partial scope means partial failures are more likely. SAP Note 2416066 prevents package data from being deleted on restart. A FINS_MIG_STATUS restart without this note implemented can corrupt the migration state in ways that require a full reset. Implement it universally, not just for shell-converted entities.

3. Migrate all split valuation types for a given material/plant in the same cutover window. Cross-system split valuation — where some types are in ECC and others in S/4HANA — creates inventory double-counting risk with no native reconciliation mechanism. The only safe position is to move all valuation types for a material/plant together. If this is not possible, obtain written sign-off on the double-counting risk and the manual reconciliation obligation before proceeding.

4. Enforce the period-end close sequencing rule throughout coexistence without exception. ECC CKMLCP for non-migrated plants must complete before S/4HANA CKMLCP for migrated plants begins — every period, without exception. Any deviation produces actual costing results that are not comparable across systems and cannot be reconciled after the fact. Document the sequence, automate the dependency check where possible, and escalate immediately if ECC close is delayed.

5. Cap coexistence at 12 months and plan the exit from day one. Coexistence is a controlled risk, not a steady state. Reconciliation complexity, master data governance fatigue, and integration layer maintenance costs grow non-linearly with coexistence duration. The exit plan — including the migration approach for remaining ECC entities — must be defined before the first SDT cutover executes, not after. If coexistence is projected to exceed 12 months, escalate to CFO/CIO level for a formal extension decision.

1. Clean ML activation for newly migrated plants. Because selectively loaded entities start fresh in S/4HANA, the ML type, currency types, actual costing configuration, and COGS Split can all be configured optimally — unconstrained by whatever legacy configuration existed in ECC. This is the one opportunity in a migration lifecycle to rationalize ML configuration without a full greenfield rebuild. Review every OMXW, OMX1, and COGS Split setting against current best practice before configuring S/4HANA.

2. Master data cleansing at entity boundary. The carve-out moment is the highest-leverage point for master data quality improvement. Because only a subset of entities migrates, the data volume is smaller and the cleansing effort is more tractable than a full-system migration. Run SAP Information Steward de-duplication for all Customer, Vendor, and Business Partner records in scope. Rationalize material master records across migrated plants. Any master data quality investment made at this stage pays dividends across the entire remaining coexistence period and beyond.

3. Integration architecture as a strategic asset. The integration layer built for SDT coexistence — ALE distribution model, SAP Integration Suite flows, cross-system reconciliation reports — is reusable beyond the migration project. If the organization operates a hybrid landscape long-term, the coexistence integration architecture becomes the foundation of the permanent integration model. Design it to production standards from the start, not as a temporary migration artifact.