SAP Master Data Migration

SAP master data migration is the first, foundational step of any ECC to S/4HANA move: the master records have to be in the target system, clean and consistent, before any transaction can reference them. The meaning of master data in SAP is simple: the records that transactions point to rather than the transactions themselves: customers, vendors, materials, G/L accounts, cost centers, profit centers, assets, banks, bills of material, prices. A sales order is transactional data; the customer and the material on it are master data, and both have to exist before the order can.

This guide takes the objects one at a time, in the order they have to be loaded. For each one it gives the transaction in ECC and in S/4HANA, the tables the data lands in, the BAPI a validated load posts through, what changed in S/4HANA, and where the free template is. Around that core it covers what changed for master data in S/4HANA, which tool loads which object, the process for each object, and how to prove a load was right.

Master data by SAP module

Every SAP module owns some master data, and a migration is usually planned module by module before it is sequenced object by object. The table below is the map between the two views: master data in SAP FI, CO, MM, SD, PP, PM and QM, with examples of master data in each, and whether it migrates at cutover. The right hand column matters most: not every master object is migrated at cutover. Some are created fresh in the target system by configuration, and some are loaded later, after the transactional history has been closed.

The types of master data in SAP MM and SD overlap on purpose. The material master has purchasing views owned by MM and sales views owned by SD, and the same physical record carries both. Customers and vendors, in S/4HANA, are two roles of one Business Partner. Planning by module is fine; loading has to be planned by object, because that is where the dependencies live.

The master data objects, in load order

The order below is the dependency order. Each object references something above it, and loading out of sequence produces the same family of errors every time: a cost center rejected because its profit center does not exist, a material rejected because its valuation class points to a G/L account that was not created, a customer rejected because the reconciliation account is missing. The order is not a suggestion. It is what the target system enforces.

What changes for master data in S/4HANA

Most master data objects migrate from ECC to S/4HANA with the same structure, the same tables and the same BAPIs. Five things changed, and they account for nearly all of the master data rework in a conversion.

Business Partner and customer vendor integration

Customer and vendor master data are roles of a single Business Partner in S/4HANA. The classic transactions no longer create records, the classic tables are filled by customer vendor integration rather than directly, and CVI has to be complete in the source system before a conversion can start. For a new implementation, the customer and vendor files become one Business Partner load. For a conversion, the CVI synchronisation is a project in its own right. Either way, the number range decision and the deduplication of partners who are both customer and supplier happen before the first load. The Business Partner automation page covers the load itself.

Extended material number

Where the extended material number is active, MATNR is 40 characters rather than 18. Activation is a business decision at the start of a project, and it is not reversible. Every source field, every mapping, every interface and every custom program that assumed 18 characters has to be checked. Where it is not active, nothing changes, and most conversions leave it off.

New Asset Accounting

New Asset Accounting is the only Asset Accounting in S/4HANA. Every depreciation area posts to a ledger, and takeover values are posted as documents rather than written into value tables. The asset master load is unchanged; the value load moves from AS91 alone to AS91 for the master plus ABLDT for the values, and the asset classes and depreciation areas have to be consistent with the ledger setup before either will accept a record.

Material Ledger

The Material Ledger is active in S/4HANA for all valuation areas. Actual costing remains optional, but the ledger itself is not. For migration this means the valuation view of every material carrying stock has to be complete and consistent before the first goods movement, and the initial stock load has to be done through a valued goods movement rather than a direct table load, so the ledger starts with a correct record.

Fiori apps for maintenance

Most master objects have a Fiori app alongside the GUI transaction: Manage G/L Account Master Data, Manage Cost Centers, Manage Product Master Data, Maintain Business Partner, Manage Fixed Assets. The GUI transactions still exist for all of the objects above. The change matters for anyone whose load method depended on recording GUI screens: a batch input recording of a transaction that has moved to an app has nothing to replay against. Loads that post through BAPIs are not affected, because a BAPI has no screens.

Which tool loads which object

Three tools appear in every S/4HANA master data migration, and they were designed for different points in the project. Choosing between them is mostly a question of when the load is happening and who is running it.

The SAP S/4HANA Migration Cockpit is SAP's tool for the initial load into a new S/4HANA system. It ships with a predefined migration object for every master object in this guide, including the two without a released BAPI (G/L account and purchasing info record), takes data from staging tables or from a connected source system, and validates and simulates before it posts. It is the right tool for the cutover load and SAP designed it for exactly that. The full guide to the Migration Cockpit covers its objects, staging tables and sequencing.

LSMW is the tool ECC teams know, and it still opens in S/4HANA on-premise. SAP classes it as restricted use, it receives no new development, and it is absent from the public cloud. Objects built on the BAPI method keep working; objects built on recordings of XD01, XK01 or any transaction that changed in S/4HANA do not. The LSMW guide has the full status and the list of what breaks.

Excel based loading through standard BAPIs is the third tool, and it covers the loads the other two were not designed for: corrections during mock loads, the master data that arrives after cutover, and every mass create and mass change that follows in normal operation. That is what PostNow does. A finance or master data user opens the sheet they already have, PostNow validates every row against the live S/4HANA system, and posts through the same BAPIs listed in the object sections above, under the user's own SAP login and authorisations. Nothing is recorded, so there are no screens to break, and nothing is transported, so there is no development request.

What those loads look like after go-live, from hypercare corrections to month end journals, has its own guide.

The migration process, object by object

The same six steps apply to every object, and the reason to run them per object rather than for the whole data set is that each object has a different owner, a different cleansing problem and a different dependency. The field mapping tracker and the data readiness checklist are built around these steps.

Extract and profile

Pull the object from the legacy system with every field, not the fields you think you need, and profile it: record counts by organisational unit, fill rate per field, distinct values for every coded field. The profile is what tells you that 40 percent of vendors have no payment terms, or that three plants use a material type that does not exist in the target. It takes a day per object and saves a week.

Cleanse

Fix what the profile found, in the source or in a staging copy, before mapping. Cleansing after mapping means cleansing twice. The two decisions that belong here and not later are deduplication (which of four bank keys survives, which customer and vendor records are the same partner) and scope (which of 60,000 materials are still used and which are archived on the way past).

Map to the target structure

Every source field to a target field, structure and value rule. This is where the BAPI structures in the object sections above become the specification: the target for a material MRP type is PLANTDATA-DISMM with PLANTDATAX-DISMM set, not "MRP type". Value mappings (legacy material type to SAP material type, legacy payment term to SAP payment term) are kept in tables, one per field, owned by the functional lead for that object. The templates carry the target structure and field for every column so this step starts from a filled sheet rather than a blank one.

Validate against the live target

Before any load, every row is checked against the target system's configuration and existing master data: does the profit center exist, is the valuation class valid for the material type, is the reconciliation account a G/L account of the right type. This is different from checking the file's format. A file can be perfectly formed and 30 percent unloadable because the configuration it references is not there yet. Validation against the live target is the step that separates a mock load that teaches you something from one that produces 12,000 error lines.

Mock load and reconcile

Load the object into the target, then reconcile: record count by organisational unit against the cleansed source, and field by field for a sample and for every field the business flagged as critical. Log every failure with its message. Fix the mapping, the cleansing or the configuration, and load again. Three mock loads is normal for the large objects; the last one should be a rehearsal of cutover timing as well as content.

Cutover load

The final load, in dependency order, against the production target, with the reconciliation from the last mock load as the acceptance criterion. Each object is signed off by its owner before the next gate opens. The run log from the load, with one line per record and a result for each, is the migration evidence and is kept.

Validation and reconciliation

A master data load is proven in three ways, and a migration sign-off needs all three.

Counts. Records loaded per object, per company code, per plant, per sales area, against the cleansed source. The counts have to match exactly, and the reconciliation has to explain every record that was in scope and did not load.

Fields. For every object, a defined list of critical fields compared value by value between source and target: reconciliation account and payment terms on partners, material type, valuation class and MRP type on materials, depreciation key and useful life on assets, rate and validity on conditions. A sample is acceptable for descriptive fields. Critical fields are compared in full.

The run log. Every row that was loaded, with the key it was given in the target, the result, and the message where the result was not success. A load that cannot produce that log has not been validated; it has been assumed. This is the artefact that an auditor asks for after go-live and the one that lets you answer "was this vendor migrated or created afterwards" a year later.

PostNow produces that log for every load, in the sheet the load came from, with the SAP result beside every row. It is the same log during mock loads, at cutover if PostNow is used for corrections, and for every load after go-live, so the evidence trail does not change format when the project team hands over.

Free templates for every master object

The 24 master data templates cover the objects above that have a released BAPI, plus cost elements, activity types, internal orders, WBS elements, batches, characteristics, classifications and HR infotypes. Every template names the BAPI, the structure and the field for every column, carries the mandatory fields the BAPI enforces, and is verified against the SAP data dictionary.

Frequently asked questions