Material Ledger Cutover: SAP ECC to S/4HANA — Part 1: Brownfield System Conversion

SAP S/4HANA mandates the Material Ledger for every system using Materials Management. There is no opt-out, no deferral, and no workaround. For organizations executing a brownfield in-place system conversion — the most common S/4HANA adoption path for large enterprises — this means the Material Ledger migration is not a workstream within the project. It is the critical path of the project.

This whitepaper covers every technical dimension of that migration: the data model transformation from MBEW/COEP/COSS to ACDOCA, the four-step FINS_MIG_STATUS execution sequence (M10/M11/M20/M21), the pre-cutover period-end close dependency chain, the SP-level note correction burden from SAP Note 2345739, the product costing scenarios that must be resolved before M10 runs, and the post-migration governance framework that determines whether go-live is operationally stable or audit-sensitive from day one.

The document is structured as a complete execution reference for SAP FI/CO consultants, enterprise architects, and project leads. It covers twelve sections from migration overview through closing recommendations, including a full risk register, a six-phase execution playbook, and a fifteen-point sign-off checklist.

Three findings dominate: first, the X-matrix in SAP Note 2345739 is non-negotiable — every marked note must be implemented before M10 regardless of perceived relevance. Second, four configuration decisions (OMXW currency types, COGS Split activation, OMX1 price determination, OMWC split valuation) are irreversible after M10 and must be made, documented, and frozen before the migration window opens. Third, a zero-difference MB5L vs FS10N reconciliation is the only acceptable entry condition for M10 — any delta carried into the migration window becomes a permanent ACDOCA opening balance error.

This is Part 1 of a three-part series. Part 2 covers greenfield new implementations using SAP Rapid Data Migration (RDM) and SAP Data Services 4.3. Part 3 covers bluefield and Selective Data Transition (SDT) scenarios combining RDM, FINS_MIG_STATUS, and third-party SDT tools.

This whitepaper is bounded to three functional domains:

• Materials Management (MM): Inventory valuation tables (MBEW, EBEW, QBEW, OBEW), goods movement history, purchase order history (EKBE/EKBZ)
• Material Ledger (ML): Mandatory in S/4HANA from release 1511 onward; migration orchestrated by FINS_MIG_STATUS
• Product Costing (CO-PC): Standard costing, actual costing (CKMLCP), mixed costing, COGS Split, WIP settlement

SAP Note 2345739 is the master coordination note for all Material Ledger migration corrections. It contains a version- and SP-gated correction matrix — an X-marked table identifying which OSS notes are absent from each S/4HANA release at each Service Pack level and must therefore be manually implemented via SNOTE before M10 can safely execute. Every project team executing a brownfield ML migration must treat this note as a living checklist.

SAP Note 2239701 delivers the SAP Rapid Data Migration (RDM) toolset for S/4HANA On-Premise. In a brownfield context, RDM is supplementary — FINS_MIG_STATUS is the primary migration engine — but RDM objects remain relevant for supplementary master data loads and for business partner migration completeness verification.

Brownfield conversion executes via SUM/DMO (Software Update Manager / Data Migration Option). The process:

1. SUM applies the software update (ECC → S/4HANA stack)
2. The ABAP-based Data Migration framework (FINS_MIG_STATUS) runs finance follow-up activities post-technical-upgrade
3. The data model migrates in-place: MBEW/COEP/COSS → ACDOCA; ML tables → MLDOC/CKMLHD/CKMLPR

No data is extracted and reloaded. The migration is a structural transformation of the existing dataset. The existing client, Customizing, transactional history, and data model are all carried forward.

The Material Ledger is obligatory in SAP S/4HANA for all systems using Materials Management. Migration is required in two scenarios:

• Migration from SAP ERP to SAP S/4HANA 1610 or higher
• Migration from SAP Simple Finance to SAP S/4HANA 1610 or higher

Critically: the Material Ledger must be migrated even if it was not active in the source ECC system.

In SAP S/4HANA, all accounting postings — FI, CO, ML, AA — converge into table ACDOCA (the Universal Journal). The Material Ledger migration writes inventory valuation history into ACDOCA with balance carryforward records (BSTAT = ‘C’, MIG_SOURCE = ‘N’). From go-live, all goods movements post directly to ACDOCA rather than to MBEW/COEP/COSS.

FINS_MIG_STATUS is the IMG activity Start and Monitor Data Migration under Migration to SAP S/4HANA Finance → Data Migration. It manages four ML-specific steps:

Split valuation is configured via OMWC (valuation category / valuation type). For brownfield:

• All valuation types within a valuation category must have consistent MBEW records before M10
• Gaps in MBEW records (valuation type exists in Customizing but has no MBEW record) are a hard M10 blocker
• The valuation category field (MBEW-BWTTY) drives the PUP-per-valuation-type logic in actual costing — CKMLPR records are created per valuation type
• Configuration freeze on OMWC must be enforced from the pre-M10 gate through go-live

Mixed costing uses multiple procurement alternatives with weighted allocation percentages. Key brownfield impacts:

• Price determination setting = 3 (single-level/multilevel) must be configured in OMX1 before M10
• All procurement alternative cost estimates must be marked and released before M10
• Incomplete or unreleased procurement alternatives produce M10 validation errors
• The cost rollup for mixed costing relies on CKMLPR records created during M10 — missing procurement alternative records cannot be retroactively created post-M10

Any change to MBEW-BKLAS affects G/L account determination (OMWB). Valuation class changes must not occur during the migration window because a changed valuation class alters the G/L account that M10 writes balance carryforward records to. Post-migration, the balance in ACDOCA would be on a different account than the FI balance in FS10N. All valuation class changes must be executed and reconciled (MB5L vs FS10N) before the period-close freeze.

The Material Ledger type assigns currency types to valuation areas. This configuration is non-reversible — it cannot be changed after M10 runs.

The selection in OMXW must be finalized and approved before the pre-M10 configuration gate is closed. Any currency type added after M10 requires a full re-run of M10.

Every item below is a hard blocker for M10. M10 will either error or produce incorrect results if any of these steps have not completed.

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

    A["CO Assessment &<br>Distribution Cycles"]:::source
    B["WIP Calculation"]:::source
    C["Prod/Process Order<br>Settlement"]:::source
    D["Sales Order Settlement"]:::source
    E["Actual Costing Run"]:::source
    F["GR/IR Clearing"]:::source
    G["Inventory Revaluation"]:::source
    H["EC-PCA Period Close"]:::source
    I["FI Period Close"]:::integration
    J["MM Period Close/Open"]:::integration
    K["Standard Cost Release"]:::source
    L["GL Balance Carryforward"]:::integration
    M["MB5L vs FS10N<br>Reconciliation — Zero Diff"]:::reporting
    N["M10 GO / NO-GO GATE"]:::target

    A --> I
    B --> C
    C --> I
    D --> I
    E --> I
    F --> J
    G --> I
    H --> I
    I --> M
    J --> M
    K --> M
    L --> M
    M --> N

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 SRC["ECC Source Layer"]
        S1["Inventory Valuation"]:::source
        S2["ML Period / Currency Records"]:::source
        S3["PO History / Delivery Costs"]:::source
        S4["ML Order Currency Records"]:::source
        S5["CO Line Items / Totals"]:::source
        S6["Profit Center Accounting"]:::source
    end

    subgraph CFG["Pre-Migration Configuration Gate"]
        C1["ML Type / Currency Types"]:::integration
        C2["Price Determination"]:::integration
        C3["Split Valuation Config"]:::integration
        C4["Valuation Class / G-L Determination"]:::integration
        C5["COGS Split Activation"]:::integration
        C6["SP-Level Corrections"]:::integration
    end

    subgraph MIG["Migration Engine — FINS_MIG_STATUS"]
        M10["Migrate ML Master Data"]:::integration
        M11["Migrate ML Transaction Data"]:::integration
        M20["Check ML Master Data"]:::integration
        M21["Check ML Transaction Data"]:::integration
        M10 --> M11
        M11 --> M20
        M20 --> M21
    end

    subgraph TGT["S/4HANA Target Layer"]
        T1["Universal Journal — Opening Balances"]:::target
        T2["ML Documents"]:::target
        T3["ML Header / Price Records"]:::target
        T4["Balance Carryforward Records"]:::target
    end

    subgraph PC["Product Costing Layer"]
        P1["Standard Cost Estimate"]:::target
        P2["Actual Costing Run"]:::target
        P3["WIP Settlement"]:::target
        P4["COGS Split Posting"]:::target
    end

    subgraph VAL["Post-Migration Validation Layer"]
        V1["Stock Value Report"]:::reporting
        V2["G-L Balance"]:::reporting
        V3["GR/IR Clearing"]:::reporting
        V4["ML Actual Cost Analysis"]:::reporting
        V5["MM Period Open/Close"]:::reporting
    end

    subgraph RPT["Reporting Layer"]
        R1["Inventory Valuation Analytics"]:::reporting
        R2["COGS Split Report"]:::reporting
        R3["Profit Center Report"]:::reporting
        R4["Group Valuation Report"]:::reporting
    end

    SRC --> CFG
    CFG --> MIG
    MIG --> TGT
    TGT --> PC
    TGT --> VAL
    VAL --> RPT
    PC --> VAL

SAP Note 2345739 is a living coordination note containing correction tables organized by S/4HANA target version and Service Pack level. Each cell in the matrix is either blank (note already included in that SP) or marked X (note is missing from that SP and must be manually implemented via SNOTE).

1. Identify the S/4HANA target version: 2021 (S4CORE 106), 2022 (S4CORE 107), 2023 (S4CORE 108), or 2025 (S4CORE 109)
2. Identify the Service Pack level (SP00 through SP08)
3. Find the version table in Note 2345739
4. Every note marked X in the SP column is not included in the system and must be implemented manually via transaction SNOTE
5. Implement all X-marked notes before M10 execution — do not selectively implement based on perceived relevance

“Not all notes are relevant for all customers. Some are specific for NZDT/DOC conversion. Some also contain manual steps for specific scenarios (don’t execute those steps). Still, by implementing all of the mentioned notes, you can prevent a large amount of issues from occurring.” — SAP Note 2345739

At SP00 — the highest-risk entry point — the X-matrix is fully populated. The table below summarizes the correction note volume at SP00 versus SP08 (counts derived from the X-matrix in the attached note; exact counts vary by customer scenario):

Recommendation: Target SP05 or higher for the S/4HANA target version to materially reduce the manual SNOTE implementation burden before M10.

Near-Zero Downtime (NZDT) and Downtime-Optimized Conversion (DOC) are SUM execution modes that perform preparatory steps in the background while the system is still online. Notes marked as NZDT/DOC-specific in Note 2345739 apply only to these execution modes and should not be executed for standard downtime conversions. Review each X-marked note’s description before implementing to confirm applicability.

Several notes in the 2345739 matrix contain mandatory manual pre- or post-steps that SNOTE implementation alone does not execute. These may include:

• Database table entries that must be inserted manually before M10
• Report programs that must be run before or after M10 to remediate specific data scenarios
• Configuration switches that must be set in the IMG

For every X-marked note, read the full note text in SAP ONE Support Launchpad before implementing. SNOTE import is not sufficient for every note.

M10 processes all valuation areas and material records. For large systems (>500K material-plant combinations), M10 can take many hours on a single process.

• Use the background job configuration within FINS_MIG_STATUS to set the number of parallel work processes for M10
• Note 2927214 specifically addresses memory shortage (TSV_TNEW_PAGE_ALLOC_FAILED) during M10 parallel execution
• HANA memory sizing for the migration window must account for the M10 working set — do not run M10 on a HANA system sized only for production steady-state
• Monitor M10 execution via SM37 and FINS_MIG_STATUS status screen; intermediate restart is possible using Note 2416066 package protection

SAP Rapid Data Migration (RDM), delivered via Note 2239701, is built on SAP Data Services 4.3. In a brownfield conversion, RDM is supplementary — not primary. The primary migration engine is FINS_MIG_STATUS. RDM becomes relevant where:

• Supplementary master data loads are required alongside the conversion
• Business Partner migration completeness must be verified before M11
• Data quality tooling is needed to clean the source before conversion

Note 2239701 contains an explicit warning: the INFREC IDoc is not supported for data transfer and SAP will provide no support for it in that context. If a project team attempts to use INFREC to load or repair Purchase Info Records during the migration window, this can corrupt EKBZ records that M11 subsequently reads. Any EKBZ corruption produces the Note 2385542 error pattern (sum of quantities = 0, sum of values ≠ 0).

M11 migrates purchase order and process order history tied to vendor records. If vendor master records have not been fully synchronized to Business Partner (BP) format before M11 runs, M11 can produce FK violations or incomplete ACDOCA records. The CVI (Customer-Vendor Integration) synchronization must complete before M11 execution.

Note 2239701 explicitly states: “Secondary Cost Element (It is not supported by SAP S/4HANA).” In S/4HANA, secondary cost elements are replaced by primary G/L accounts in the chart of accounts. For brownfield, this affects:

• Assessment cycles (KSU5): Sender cost elements must be mapped to G/L accounts in S/4HANA; configuration must be updated before go-live
• COGS Reporting: Secondary CElem-based COGS splits must be reconfigured to use G/L account-based COGS Split activated pre-M10
• Costing Sheets: Secondary cost elements in overhead costing sheets must be replaced with primary accounts
• Data migration: The RDM object for Secondary Cost Elements has no migration path. They are replaced by G/L accounts that must be created in the S/4HANA chart of accounts before go-live. Any custom reporting referencing secondary cost element ranges must be reconfigured to reference G/L account ranges

SAP Note 2287723 (referenced by Note 2239701) confirms that LSMW is deprecated in SAP S/4HANA On-Premise and Private Cloud. Any brownfield project that relied on LSMW for supplementary master data loads must migrate those processes to:

• SAP Migration Cockpit (LTMC) — preferred for standard objects
• SAP Data Services via RDM content (Note 2239701) — preferred for high-volume or complex transformations
• Direct BAPI/IDoc calls — for custom integration scenarios

M10 is the foundational ML migration step. It activates the Material Ledger for all valuation areas in scope and migrates inventory valuation master data into the S/4HANA data model.

Tables read (source):

Tables written (target):

Parallel processing: M10 supports parallel processing via package-based distribution across work processes. Configure the number of parallel jobs in FINS_MIG_STATUS before execution. For systems with >200K material-plant records, a minimum of 8 parallel work processes is recommended. Monitor via SM37.

Hard prerequisites for M10:

• All period-end close activities from Section 3 complete
• All X-marked notes from Note 2345739 implemented via SNOTE
• OMXW currency type assignment finalized and frozen
• MB5L vs FS10N reconciliation = zero difference
• FI and MM periods aligned

M11 converts purchase order history, delivery cost records, and ML order currency records from ECC format to the S/4HANA ACDOCA-based format.

Tables read (source):

Tables written (target):

Dependency: M11 requires M10 to be in COMPLETED status. M11 reads the CKMLHD and CKMLPR records created by M10 as foreign key references.

Key risk: EKBZ quantity/value mismatch (Note 2385542). If the sum of quantities across EKBZ records for a PO item is zero but the sum of values is not zero, M11 produces a hard error. This must be remediated in the source system before M11 execution.

M20 is a validation step, not a data migration step. It compares the migrated ACDOCA records against MLDOC_EXTRACT to verify that all inventory valuation balances migrated correctly.

Check logic:

• For each material/plant/valuation type/currency type combination: ACDOCA balance = MBEW-derived expected value
• Price control consistency: S-materials have standard price in ACDOCA; V-materials have MAP
• Currency type completeness: all currency types defined in OMXW have corresponding ACDOCA records
• Special stock completeness: EBEW, QBEW, OBEW records verified in ACDOCA

Error resolution:

1. Run M20 in simulation mode first (FINS_MIG_STATUS → M20 → Test Run)
2. Review error log in SLG1 (object: FINS_MIG, subobject: ML_MIGRATION)
3. For each error category, apply the relevant note from the 2345739 matrix or execute the documented manual correction
4. Re-run M20 until zero errors
5. Proceed to M21 only after M20 is error-free

M21 validates the M11 migration output. It verifies that PO history and production order history records in ACDOCA are consistent with the source EKBE/EKBZ/MLAUFCR records.

Check logic:

• PO quantity and value totals in ACDOCA match EKBE totals per PO item
• Delivery cost totals in ACDOCA match EKBZ totals per PO item
• ML order currency records in ACDOCA match MLAUFCR totals
• Business Partner existence verified for all vendor-linked records

Completion gate: When M20 and M21 both reach status COMPLETED in FINS_MIG_STATUS, the ML migration is complete and the system is unlocked for go-live processing.

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

    A["Period-End Close Complete"]:::source
    B["MB5L = FS10N Zero Diff"]:::source
    C["Note 2345739 X-Notes Done"]:::source
    D["Configuration Frozen"]:::source

    E["FINS_MIG_STATUS Pre-Check"]:::integration
    F{"Pre-Check<br>Errors?"}
    G["Resolve Pre-Check Errors"]:::integration

    H["M10 — Migrate ML Master Data"]:::integration
    I{"M10<br>Status?"}
    J["M10 Error Resolution"]:::integration

    K["M11 — Migrate ML Transaction Data"]:::integration
    L{"M11<br>Status?"}
    M["M11 Error Resolution"]:::integration

    N["M20 — Check ML Master Data"]:::integration
    O{"M20<br>Status?"}
    P["M20 Error Resolution"]:::integration

    Q["M21 — Check ML Transaction Data"]:::integration
    R{"M21<br>Status?"}
    S["M21 Error Resolution"]:::integration

    T["FINS_MIG_STATUS = ALL COMPLETED"]:::target
    U["Go-Live Unlocked"]:::target

    A --> E
    B --> E
    C --> E
    D --> E
    E --> F
    F -->|Yes| G
    G --> E
    F -->|No| H
    H --> I
    I -->|Error| J
    J --> H
    I -->|Completed| K
    K --> L
    L -->|Error| M
    M --> K
    L -->|Completed| N
    N --> O
    O -->|Error| P
    P --> N
    O -->|Completed| Q
    Q --> R
    R -->|Error| S
    S --> Q
    R -->|Completed| T
    T --> U

• A current-period released standard cost estimate must exist for every S-material in every plant before M10 runs
• In ECC, S-materials carry a statistical moving average price alongside the standard price. In S/4HANA, the statistical MAP is eliminated. Reports relying on MBEW-VERPR for S-materials will break post-migration and must be redesigned to use ACDOCA-based price variance reporting
• Execute CK40N (mass costing) and ensure all cost estimates are in Released status before M10

• Actual costing is optional. If active in ECC, source CKMLPP/CKMLCR data is fully migrated by M10
• If actual costing was not active in ECC and is to be activated in S/4HANA, activation must occur before M10 with the correct configuration in OMX1 (price determination = 3)
• Post-M10, CKMLCP runs in S/4HANA follow the same sequence as ECC: preliminary costing → actual price determination → revaluation posting → WIP revaluation → balance sheet revaluation
• ML documents are created per goods movement in ACDOCA from go-live onward; historical ML documents from ECC are migrated via M10/M11

• Requires price determination = 3 in OMX1 and correctly configured procurement alternatives before M10
• The multilevel cost rollup in S/4HANA uses CKMLPR records (created by M10) as the basis for mixed price calculation
• All procurement alternative cost estimates must be marked and released before M10; incomplete procurement alternatives produce M10 errors that cannot be resolved post-migration without a full M10 reset

• When split valuation is active, actual costing creates a separate CKMLPR record per valuation type within the valuation category
• The Periodic Unit Price (PUP) is calculated per valuation type, not at the aggregate material/plant level
• All valuation types must have complete MBEW records before M10; missing valuation type records cause M10 to create incomplete CKMLPR records, resulting in M20 errors

COGS Split enables disaggregation of Cost of Goods Sold into cost components posted to separate G/L accounts on the goods issue.

• Activation requirement: COGS Split must be activated and configured before M10. Activating COGS Split after M10 requires a partial ML migration reset and is not supported in a live system
• Cost component to G/L mapping: Each cost component structure element must be mapped to a specific G/L account in the COGS Split configuration
• Day 1 configuration: The mapping must be complete before the first goods issue posting in S/4HANA. Any goods issue posted before the mapping is complete posts COGS to the default account without disaggregation — this cannot be retroactively split

Parallel COGM is available in the cloud edition of SAP S/4HANA only via Universal Parallel Accounting. For S/4HANA On-Premise (the target in scope for this whitepaper), parallel COGM is not available as a standard feature. Currency types 30/31/32 provide parallel valuation for inventory and COGS but do not provide a full parallel COGM calculation.

• Currency type 32 in ACDOCA carries the profit center valuation (transfer price valuation), replacing EC-PCA
• EC-PCA data (tables GLPCA, GLPCT) is migrated to ACDOCA currency type 32 records during the FI migration steps (F-series steps in FINS_MIG_STATUS)
• The 2KES EC-PCA period close must complete before M10; any open EC-PCA period leaves currency type 32 records in an indeterminate state
• Post-migration, profit center reports are driven directly from ACDOCA filtered by currency type 32 — the separate EC-PCA ledger no longer exists
• Transfer pricing configuration must be reconfigured in the S/4HANA Profit Center Valuation framework before go-live

• Currency types 30 (group currency, legal valuation) and 31 (group currency, group valuation) in ACDOCA carry group valuation, replacing the parallel ledger approach for group reporting in ECC
• Currency types 30/31 must be assigned in OMXW before M10 — they cannot be added post-M10 without a full migration reset
• Group valuation requires that intercompany elimination entries and transfer price adjustments be configured in the S/4HANA Group Valuation framework before go-live

• WIP must be fully settled or zeroed via KKAO/CO88 before M10
• Any residual WIP in COEP/COSS at M10 execution time is migrated to ACDOCA as a WIP balance carryforward record — if unintentional, this produces incorrect opening balances that are difficult to correct post-go-live
• Post-migration WIP verification: run KKAO in display mode and cross-check WIP balances in ACDOCA (filter RWTYPE = 'WIP') against the expected zero or settled position
• Note 2387172 addresses specific WIP and CCS migration corrections relevant to this scenario

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 P1["Phase 1 — Assess & Prepare (8–12 wks)"]
        A1["Version / SP Confirm"]:::source
        A2["Note 2345739 X-Matrix Analysis"]:::source
        A3["ATC Custom Code Scan"]:::source
        A4["OMXW / OMX1 / OMWC Decisions"]:::source
        A5["EKBZ / MBEW Data Quality Checks"]:::source
        A6["Secondary CElem Mapping"]:::source
    end

    subgraph P2["Phase 2 — Configure & Remediate (4–8 wks)"]
        B1["SNOTE Implementation"]:::integration
        B2["Config Freeze"]:::integration
        B3["COGS Split Activation"]:::integration
        B4["EKBZ / MBEW Remediation"]:::integration
        B5["CVI / BP Sync Complete"]:::integration
        B6["Secondary CElem to G-L Migration"]:::integration
    end

    subgraph P3["Phase 3 — Mock Cutovers (2–4 wks)"]
        C1["Full Period Close in Mock"]:::integration
        C2["FINS_MIG_STATUS Mock Run"]:::integration
        C3["ACDOCA Validation in Mock"]:::integration
        C4["First CKMLCP in Mock"]:::integration
        C5["Elapsed Time Measurement"]:::integration
    end

    subgraph P4["Phase 4 — Period Close & Freeze (Final Week)"]
        D1["Full Period Close Sequence"]:::source
        D2["MB5L = FS10N Zero Difference"]:::source
        D3["Transaction Freeze"]:::source
        D4["Go / No-Go Sign-Off"]:::source
    end

    subgraph P5["Phase 5 — Cutover Execution (Migration Window)"]
        E1["SUM / DMO Technical Upgrade"]:::integration
        E2["SNOTE Re-Verification"]:::integration
        E3["M10 Execute & Monitor"]:::integration
        E4["M11 Execute & Monitor"]:::integration
        E5["M20 Execute — Zero Errors"]:::integration
        E6["M21 Execute — Zero Errors"]:::integration
        E7["FINS_MIG_STATUS = ALL COMPLETED"]:::target
        E8["Post-Migration Reconciliation"]:::target
        E9["Go-Live Authorization"]:::target
    end

    subgraph P6["Phase 6 — Hypercare & Validation (4 wks)"]
        F1["Daily MB5L vs FS10N"]:::reporting
        F2["SLG1 / SM37 Monitoring"]:::reporting
        F3["First CKMLCP Run"]:::reporting
        F4["COGS Split Verification"]:::reporting
        F5["Custom Code Regression"]:::reporting
        F6["Hypercare Sign-Off"]:::reporting
    end

    P1 --> P2
    P2 --> P3
    P3 --> P4
    P4 --> P5
    E1 --> E2
    E2 --> E3
    E3 --> E4
    E4 --> E5
    E5 --> E6
    E6 --> E7
    E7 --> E8
    E8 --> E9
    P5 --> P6

The first period-end close in S/4HANA is operationally higher risk than any subsequent close. Execute every step below in sequence; do not parallelize CO and FI close until the second period.

CKM3N — Material Ledger Actual Costing Document:

SLG1 — Application Log:

Review SLG1 for the above objects after every period-end close during the first three months post go-live. Reduce to quarterly review after stable operation is confirmed.

1. Implement every X-marked note from SAP Note 2345739 before M10 — no exceptions. The X-matrix is the product of years of accumulated field issues across thousands of brownfield conversions. Selective implementation based on perceived relevance is the single most common cause of M10/M11 failures in the field. Implement all notes, read the manual steps for each, and verify via SNOTE status before the migration window opens.

2. Freeze OMXW currency type assignment before M10 and treat it as irreversible. Currency types 10/30/31/32 in OMXW cannot be changed after M10 runs without a full ML migration reset — which in a production system is effectively impossible. The business decision on group valuation (types 30/31) and profit center valuation (type 32) must be made, documented, and signed off before the configuration freeze date, not during the migration window.

3. Achieve zero MB5L vs FS10N difference before entering the migration window. Any non-zero reconciliation difference at M10 entry produces ACDOCA opening balances that do not tie to FI. This cannot be corrected post-M10 without manual ACDOCA journal entries, which are auditor-sensitive and operationally disruptive. Resolve every reconciliation difference in the source system before period-close freeze.

4. Complete COGS Split activation and cost component G/L mapping before M10. COGS Split cannot be activated after go-live without a migration reset. The first goods issue in S/4HANA must post to disaggregated COGS G/L accounts. Any delay in the COGS Split decision means the first period of S/4HANA operations produces COGS data that cannot be split retroactively — a permanent reporting gap.

5. Size HANA memory for the M10 migration working set, not steady-state production. M10 parallel processing loads all MBEW/EBEW/QBEW/OBEW records and CKMLPP/CKMLCR data into memory simultaneously across multiple work processes. Systems sized for production steady-state will encounter TSV_TNEW_PAGE_ALLOC_FAILED (Note 2927214) during M10. Test the memory profile during mock cutovers and provision additional HANA memory for the migration window if needed.

1. Activate actual costing if it was not active in ECC. Brownfield conversion is the lowest-friction point to activate actual costing. M10 creates the full CKMLHD/CKMLPR infrastructure regardless of whether actual costing was active in ECC. Activating it at go-live adds marginal incremental cost to the project while delivering periodic unit price visibility, multilevel actual cost rollup, and COGS at actual cost — capabilities that require a full reimplementation to add post-go-live.

2. Eliminate secondary cost elements and redesign allocation architecture. The forced elimination of secondary cost elements is an operational disruption only if treated reactively. Treated proactively, it is an opportunity to rationalize the CO allocation architecture: consolidate redundant assessment cycles, redesign cost component structures, and align COGS Split G/L accounts with management reporting requirements. Projects that complete this work in Phase 2 emerge with a materially cleaner CO-PC landscape than they entered with.

3. Establish ACDOCA as the single source of truth for inventory and cost reporting. Post-migration, MBEW, COEP, COSS, and GLPCA no longer exist as operative tables. All inventory valuation, cost object accounting, and profit center accounting reads from ACDOCA. Projects that redesign their reporting layer — Fiori embedded analytics, custom ABAP reports, BW extractors — to read directly from ACDOCA during the brownfield project avoid a second wave of report remediation post go-live. The investment in ACDOCA-native reporting during the project pays dividends across every subsequent reporting cycle.