The 2027 SAP ECC end-of-mainstream-maintenance deadline is not a surprise. Every pharma CIO knows it. What many do not yet grasp is what migrating to S/4HANA actually does to the data architecture underneath batch management and serialisation- and what that means for FDA 21 CFR Part 11, MHRA GxP, and DSCSA track-and-trace compliance.
This is not a "lift and shift" situation. S/4HANA fundamentally restructures how goods movements are recorded. The legacy tables your custom derivation logic, audit trail queries, and third-party track-and-trace connectors depend on have been replaced. Custom ABAP code built on MSEG, MKPF, and CHVW will fail validation checks or produce silent data gaps during cutover. Historical serial numbers may not carry forward with the audit trail continuity that regulators require.
The pharma companies that treat this as a database migration will face the companies that treat it as an architectural redesign at a severe disadvantage- both in migration timelines and in post-go-live compliance exposure.
This post gives pharma IT leaders the architectural specifics: what changed, what breaks, and what a validated migration approach looks like in 2026.
Why S/4HANA Changes the Game for Pharma Batch Data
BLUF: S/4HANA's redesigned data model is not backward-compatible with ECC batch and serial custom code. For pharma, this creates a direct regulatory compliance risk if the migration is not architecturally planned.
The 2027 Deadline and GxP Compliance Stakes
SAP's mainstream maintenance for ECC 6.0 ends in 2027. Extended maintenance options exist, but they are not indefinite, and they do not resolve the fundamental issue: staying on ECC means falling further behind on regulatory-aligned functionality in S/4HANA, including updated Annex 11 and 21 CFR Part 11 audit trail tooling native to the new platform.
For pharma, "compliance" is not a software feature. It is a business condition. An FDA warning letter citing broken batch audit trails, or an MHRA finding on serialisation gaps during a system migration, carries consequences that no IT project budget can absorb. Over 60% of S/4HANA migration delays are attributed to unstructured master data and custom code around batch management. (Source: Deloitte 2024 SAP Migration Report.) That statistic is not abstract for a pharma IT team carrying GxP obligations.
By 2027, over 80% of ERP migrations will be driven by compliance and regulatory mandates, particularly in life sciences. (Source: Gartner 2024 ERP Forecast.) The clock is running, and the planning window for a validated migration is narrowing.
Why "Lift and Shift" Fails for Batch and Serial
A lift-and-shift migration- moving ECC data into S/4HANA without re-engineering the underlying data model- produces immediate structural failures for batch and serial data.
The core problem is table architecture. In ECC, goods movements write to two separate tables: MSEG (document segment) and MKPF (document header). In S/4HANA, these are consolidated into a single universal journal table, ACDOCA, and materials management movement data is held in MATDOC. Any custom ABAP that reads MSEG or MKPF directly will either return null results or fail during runtime. Batch classification data, stored in CHVW and related classification tables, also behaves differently under the S/4HANA data model due to changes in how class hierarchies and characteristic values are stored.
For serialisation, the serial number profile configuration in ECC does not map one-to-one to the S/4HANA Extended Warehouse Management (EWM) architecture. Companies that integrated ECC WM with external track-and-trace systems via BAPI or RFC calls will find those interfaces require re-engineering, not just re-pointing.
The risk is not just technical breakage. It is the gap in audit trail continuity that occurs when historical data is loaded without proper transformation- and that gap is precisely what a GxP auditor will look for.
Batch Management vs. Serialisation: The S/4HANA Reality
BLUF: Batch management and serialisation serve different regulatory functions in pharma. S/4HANA handles both differently than ECC, and the distinction matters for how each must be migrated and validated.
Batch Management in Pharma: Expiry, Shelf Life, and Potency
In pharma, a batch is not just a production lot. It is the unit of regulatory identity. Batch-level attributes- expiry date, shelf life, potency, country of manufacture, retest date- are the core of GxP traceability. These attributes are stored as classification characteristics in ECC and must be migrated not just as data records, but with their full classification hierarchies intact.
In S/4HANA, the "Manage Batches" Fiori app replaces the ECC transaction MB56 and associated batch search transactions. The architecture for batch-specific characteristics in S/4HANA uses a refined classification engine, and custom classification schemas built in ECC- particularly those using batch-specific class types like 023- require validation after migration to confirm that all characteristic values transferred correctly and are queryable in the new Fiori environment.
Pharma companies leveraging S/4HANA for track-and-trace report a 40% reduction in data reconciliation times compared to ECC-based operations. (Source: SAP 2024 Life Sciences Value Index.) That efficiency is real, but only achievable if the underlying batch data architecture is migrated correctly.
Serialisation: Track-and-Trace and Counterfeit Prevention
Serialisation operates at the individual unit level. Under DSCSA (in the US) and the EU Falsified Medicines Directive, every saleable unit must carry a unique identifier- a serial number- that can be tracked through the supply chain from manufacturer to dispenser.
In ECC, serial numbers are managed through Serial Number Profiles attached to material master records. The transaction IQ09 and associated serial number information records (EQUI, EQKT, OBJK) are the backbone of this process. In S/4HANA, the serial number architecture shifts. EWM becomes the primary execution layer for warehouse-level serial number processing, and the integration between the core S/4HANA system and EWM uses a different data exchange model than the older ECC WM decentralized setup.
Critically, historical serial number records must be migrated in a way that preserves their document linkage- the connection between a serial number, a goods movement, a sales order, and a delivery. Breaking that linkage creates an audit trail gap that renders historical records non-compliant for regulatory lookback.
Under the Hood: How S/4HANA Architecture Reshapes Batch & Serial
BLUF: Three specific architectural changes in S/4HANA- MATDOC consolidation, Fiori app replacements, and EWM serialisation restructuring- will break ECC custom code and require deliberate remediation before migration.
The Death of MSEG/MKPF: Enter the MATDOC Table
This is the technical change with the widest blast radius for pharma IT.
In ECC, every goods movement writes a header record to MKPF and line-item records to MSEG. Virtually every custom report, batch audit trail query, and third-party connector in a pharma ECC system touches one or both of these tables directly.
In S/4HANA, goods movement data is written to MATDOC (materials document). MSEG and MKPF still exist as compatibility views, but they are read-only projections, not live tables. Custom code that reads from these views will not fail immediately during migration, but it will behave inconsistently- especially for documents created post-migration- and will not reflect the full fidelity of the underlying MATDOC data model.
Any custom code that writes to MSEG or MKPF (which ECC allowed through certain enhancement techniques) will hard-fail in S/4HANA. SAP's ABAP Test Cockpit (ATC) and the Custom Code Migration Worklist tool will flag these, but remediating them requires understanding the new data model, not just following the flag.
For pharma, the specific concern is batch split documents, process order goods movements, and quality inspection lot linkages- all of which rely on MSEG/MKPF table reads in typical ECC custom audit trail code.
Replacing ECC Transactions with S/4HANA Fiori Apps
The ECC transaction landscape for batch and serial management does not migrate forward. The replacement Fiori apps are not equivalents- they represent a different interaction model with different underlying APIs.
Key replacements relevant to pharma operations:
User training is a consideration, but the deeper issue is that workflows built around ECC transaction codes- including those in validated SOPs for GxP operations- must be formally revalidated against the Fiori equivalents before go-live.
Serial Number Profile Changes and EWM Integration
In ECC, serial number management is configured through Serial Number Profiles (transaction OIS2) and attached to the material master at the plant level. The profile controls when serial numbers are required (goods receipt, goods issue, delivery, etc.) and how they are recorded.
In S/4HANA with EWM, the execution layer for serial number assignment shifts to EWM warehouse tasks and handling unit management. The S/4HANA core still holds the serial number master (EQUI table and Equipment records), but the moment-of-capture for serial numbers in warehouse operations moves to EWM processes.
This creates an integration point that must be architecturally mapped during migration. Companies using decentralized EWM in ECC face a different migration path than those using embedded EWM in S/4HANA. The licensing implications differ as well- embedded EWM in S/4HANA is included in the S/4HANA license, while a separate decentralized EWM system carries additional licensing costs.
For pharma serialisation under DSCSA, the timing of serial number recording relative to the goods movement document is also a compliance consideration. This timing changes in the EWM-driven model and must be validated against regulatory requirements before go-live.
Migration Pitfalls: Protecting Your Audit Trail During Cutover
BLUF: The three highest-risk areas during a pharma S/4HANA migration are historical batch master data conversion, custom batch derivation code, and post-migration data integrity validation. Each requires a specific remediation approach.
Handling Historical Batch Master Data and Class Characteristics
The migration of historical batch master data is a multi-layer problem. It is not sufficient to migrate the batch header record (the MCHA/MCHB stock data). The classification characteristics that define the batch- expiry date, potency, retest date, country of origin, quality status- must also migrate, with their full characteristic value histories, into the S/4HANA classification engine.
The standard SAP migration tooling (LTMC / SAP S/4HANA Migration Cockpit) handles batch master migration, but it has known limitations with complex classification hierarchies and with batch-specific class types that carry large numbers of characteristic values. Pharma environments with tens of thousands of active batches and deep classification schemas typically require custom migration objects or pre-processing steps to normalize the data before loading.
Historical batch-level goods movement history- the document chain from goods receipt through quality inspection, production consumption, and goods issue- does not automatically migrate as live documents. SAP typically recommends archiving historical ECC documents and providing read-only access via an archiving solution or a parallel ECC system kept in a read-only state post-cutover. The audit trail implication is that historical lookback queries will span two systems for a defined period, which must be addressed in the validation approach.
Custom Code Remediation for Batch Derivation
Batch derivation- the rule-based logic that assigns a batch number automatically during goods movements- is one of the most heavily customized areas in pharma ECC environments. Custom batch derivation logic typically uses user exits, BAdi implementations, or function module substitutions that read MSEG data, check batch classification values, and apply business rules.
In S/4HANA, the batch derivation framework has been redesigned. The enhancement points are different, the table reads must target MATDOC instead of MSEG, and the sequence of BAdI calls has changed. Custom derivation code that worked correctly in ECC can produce incorrect results in S/4HANA without failing outright- the most dangerous failure mode in a validated GxP environment.
The remediation approach is: identify all custom batch derivation enhancements via the Custom Code Migration Worklist; test each in a sandbox S/4HANA system with real production data scenarios; re-implement using the S/4HANA BAdI architecture (specifically, the Business Add-In MB_BATCH_SOURCE_DETERMINATION and its S/4HANA equivalents); and validate the results against a predefined set of batch derivation scenarios that cover all material types and movement types in scope.
Validating Data Integrity Post-Migration
Post-migration data integrity validation in a GxP environment is not optional and not a single-pass exercise. It requires a formal validation protocol- typically an Operational Qualification (OQ)- that tests the integrity of migrated batch and serial data against predefined acceptance criteria.
Specific validation checkpoints for pharma S/4HANA migrations include: batch-level stock reconciliation (total quantities in ECC match total quantities in S/4HANA by batch and storage location); classification characteristic value verification (a statistically significant sample of batches validated for all critical characteristic values); serial number linkage verification (serial numbers associated with sales deliveries and goods movements have intact document chains); and audit trail query equivalence testing (audit trail queries executed in ECC and in S/4HANA return equivalent results for the same batch or serial number).
The validation effort is substantial, but it is the documentation that protects the organization in a regulatory inspection. Every data discrepancy identified and resolved during validation, with documented root cause and correction, is evidence of a controlled process. Discrepancies found by an auditor post-go-live are evidence of the opposite.
How ITChamps Secures Your Pharma Data in S/4HANA
BLUF: ITChamps brings a validated, pharma-specific migration methodology that addresses the architectural risks in this post directly- combining technical precision on batch/serial data objects with SAP Gold Partner delivery capability.
Proprietary Validation Framework for GxP Data
ITChamps' zero-defect batch data conversion methodology ensures 100% GxP audit trail integrity across pharma S/4HANA migrations. This is not a general-purpose data migration approach adapted for pharma. It is a framework built specifically around the regulatory requirements of FDA 21 CFR Part 11, Annex 11, and DSCSA, with validation documentation designed to satisfy GxP audit expectations at each migration phase.
The framework addresses the specific failure points detailed in this post: custom code identification and remediation for batch derivation enhancements; pre-migration classification data normalization; MATDOC-aligned migration object configuration; and post-migration reconciliation protocols that generate audit-ready evidence.
ITChamps delivers up to 30% faster S/4HANA migration timelines via this proprietary pharma-data validation framework. (See Compliance Disclosures.) As an SAP Gold Partner, ITChamps works within SAP's validated toolchain- the SAP S/4HANA Migration Cockpit, ABAP Test Cockpit, and SAP Readiness Check- rather than against it.
For pharma organizations assessing their current ECC environment, ITChamps offers an S/4HANA Readiness Assessment for Pharma that maps current batch/serial custom code, classification schemas, and track-and-trace integrations against the S/4HANA architecture to identify and size the gap before the project begins.
Seamless EWM and Track-and-Trace Integration
Track-and-trace is not a feature to be configured after go-live. It is a capability that must be architecturally embedded in the S/4HANA and EWM design from the start of the migration project.
ITChamps' delivery approach includes: EWM integration design for serial number capture workflows aligned with DSCSA serialisation timelines; connector re-engineering for third-party track-and-trace platforms (where existing RFC or BAPI-based ECC integrations must be replaced with S/4HANA APIs or iDocs); and licensing optimization for embedded versus decentralized EWM based on the client's operational footprint.
The EWM serialisation architecture in S/4HANA, when correctly implemented, provides a materially stronger platform for DSCSA and EU FMD compliance than ECC-based serialisation- with native Fiori visibility into serial number status, improved handling unit management, and a more auditable data model. Getting to that outcome requires the architectural work described throughout this post.
Frequently Asked Questions
Will my ECC batch master data automatically migrate to S/4HANA?
Not automatically, and not completely. SAP's Migration Cockpit supports batch master migration, but classification characteristics- the attributes like expiry date, potency, and retest date that define a batch in pharma- require additional migration objects and pre-processing for complex schemas. Historical goods movement documents associated with batches are typically archived rather than migrated as live documents, which creates a dual-system lookback requirement that must be addressed in your validation approach.
Does S/4HANA still use MSEG and MKPF tables?
MSEG and MKPF exist in S/4HANA as compatibility views, not as live database tables. The actual goods movement data is written to MATDOC. Custom ABAP code that reads MSEG or MKPF will not fail immediately, but it will return incomplete or inconsistent results for documents created after go-live, and any code that writes to these tables will hard-fail. All custom code that touches MSEG, MKPF, or CHVW must be identified, assessed, and remediated before migration.
How does S/4HANA EWM affect our DSCSA serialisation compliance?
In S/4HANA with EWM, the moment of serial number capture for warehouse operations shifts from the ECC WM execution layer to EWM warehouse tasks and handling unit management. This changes the timing of serial number recording relative to goods movements, which is a compliance consideration under DSCSA. The EWM architecture must be designed to ensure serial number assignment occurs at the correct point in the fulfillment workflow, and any third-party DSCSA platform integrations must be re-engineered from ECC RFC/BAPI interfaces to S/4HANA API or iDoc-based connectivity.
What is the risk of lift-and-shift migration for pharma batch data?
A lift-and-shift approach- moving ECC data into S/4HANA without re-engineering for the new data model- creates three specific risks for pharma. First, custom batch derivation and audit trail code will produce incorrect or null results against MATDOC, potentially creating compliance gaps that are not immediately visible. Second, classification characteristic data may not transfer with full fidelity, producing batch records that are incomplete under GxP standards. Third, serial number linkages to historical documents may break, removing the document chain that regulators require for lookback. Each of these risks requires architectural remediation, not a simple data reload.
How long does a validated pharma S/4HANA batch/serial migration take
Migration timelines depend on the complexity of the existing ECC environment- specifically the volume of custom batch derivation enhancements, the depth of classification schemas, the number of serialised material types, and the scope of third-party track-and-trace integrations. There is no standard timeline that applies universally. An S/4HANA Readiness Assessment is the correct starting point for sizing the effort, as it maps current-state complexity against the required S/4HANA architecture to produce a defensible project estimate.
Compliance Disclosures
SAP, S/4HANA, SAP ECC, SAP EWM, SAP Fiori, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries. ITChamps is an independent SAP Gold Partner. This content is published for informational purposes and does not constitute legal, regulatory, or compliance advice.
Migration timeline claims, including references to "up to 30% faster S/4HANA migration timelines," reflect ITChamps' historical client experience using its proprietary pharma-data validation framework. Actual timelines vary based on project scope, existing system complexity, data volumes, and client-specific regulatory requirements. No specific migration timeline is guaranteed.
The claim that "100% GxP audit trail integrity" is ensured reflects ITChamps' methodology and post-migration validation commitment. Outcomes are dependent on project scope, client data quality, and engagement model. Individual results may vary.
Statistics cited from third-party sources (Gartner, Deloitte, SAP) are referenced for contextual accuracy. ITChamps does not warrant the accuracy of third-party research. Readers are encouraged to consult primary sources.