Migration in brief

When a company moves to SAP S/4HANA through a new implementation, its data does not move by itself. Someone extracts it from the legacy system, cleanses and transforms it, and loads it into the new system. For most business objects, SAP's tool for the load is the SAP S/4HANA Migration Cockpit, used through the SAP Fiori app Migrate Your Data – Migration Cockpit. In older on-premise releases the same cockpit ran in SAP GUI under transaction LTMC; newer releases use the Fiori app.

This course is about the part of migration that belongs to the business: proving that what arrived in SAP S/4HANA is complete, accurate and usable. The migration team runs the tool. Key users, process owners and finance practitioners decide whether the result is good enough to run the business on.

Who does what

Three groups share the work, and confusion between them is the most common source of migration stress. The data owners in the business decide what data moves, which records are excluded, and what the cleansed values should be. The migration team builds the extracts, maintains the mapping, runs the cockpit and fixes technical errors. The business validators, usually key users and finance practitioners, check the loaded result against the legacy source and recommend acceptance. Often the data owner and validator are the same person or team; the migration team should never be the one that validates its own load.

Group	Owns	Does not own	Contoso
Data owners	What moves, exclusion rules, cleansed values	Running the load tool	Dan for finance data; Maria for customers and prices
Migration team	Extracts, mapping tasks, cockpit runs, technical errors	Deciding the data is fit for business	Migration consultants under Luis's cutover plan
Business validators	Checks against legacy, difference log, acceptance recommendation	Fixing extracts or mappings	Key users per object, supported by Priya

Three groups share migration work; separating loading from validating keeps the checks independent.

The Sign-Off Table · thesignofftable.com/academy/sap-xpr-303

In SAP S/4HANA Cloud Public Edition the cockpit works the same way at a business level, but the options are narrower: the predefined objects are what you get, while on-premise and Private Edition projects can extend or create objects with the migration object modeler. If your project uses custom objects, ask how each was tested before you rely on it.

Migration objects

The cockpit organizes data into migration objects. Each object represents one business thing the system knows how to create: a business partner acting as customer or supplier, a product, a bank, an open accounts receivable item, a G/L account balance, an inventory balance, an open purchase order. Each object comes with a predefined structure of fields, and the cockpit loads it using the same application logic and checks a user would trigger when creating the record in the standard apps. That is why a loaded record behaves like a normally created one.

Category	Typical migration objects	Who validates at Contoso
Master data	Bank; customer and supplier (business partners); product; bill of material; routing; purchasing info record; condition records for prices	Maria (customers, prices), purchasing key user (suppliers, info records), plant key users (products, BOMs)
Open items	Accounts receivable open items; accounts payable open items; open sales orders; open purchase orders	Dan and the AR/AP leads; Maria for open sales orders
Balances	G/L account balances; inventory balances (quantity and value by plant and storage location); fixed assets with values	Dan for G/L and assets; plant controllers for stock

Typical object families. The exact object list and names vary by release and deployment; check the list in your own system.

How a load runs

The migration team creates a migration project in the app and selects the objects in scope. Data reaches the cockpit in one of two ways. With staging tables, the team fills a downloadable template (XML or CSV) or fills the staging tables directly with an extraction tool. With direct transfer, the cockpit reads from a supported SAP source system over a connection. Either way, the same steps follow.

Fill source dataTemplate upload or staging tables, or direct read from an SAP source
Process mapping tasksMap legacy values to SAP S/4HANA values, for example old payment terms to new keys
SimulateRun the load through the application checks without saving anything
MigrateCreate the records; the log shows successes, warnings and errors
Business validationKey users prove completeness and accuracy in the standard apps

The steps for each migration object. Business validation is the step this course is about.

The Sign-Off Table · thesignofftable.com/academy/sap-xpr-303

Mapping tasks deserve attention from the business. A mapping says, for example, that legacy payment term N30 becomes SAP payment term 0001, or that legacy customer group FLEET becomes customer group 01. A wrong mapping loads every record successfully and wrongly. Ask to review the mapping values for the fields you own before the first full load.

Simulation is a dry run: the records pass through the same checks but nothing is saved. It finds missing configuration and invalid values early. It does not prove the data is right for the business, only that the system will accept it.

Where to check the result

Validate in the same apps users will work in after go-live, not in the migration tool. For each object, SAP's documentation names the app used to check the result. At Contoso that means Manage Business Partner Master Data or BP for customers and suppliers, Manage Product Master Data or MM03 for products, Manage Customer Line Items or FBL5N for open receivables, Manage Supplier Line Items or FBL1N for payables, Trial Balance for G/L balances, and MB52 or MMBE for stock.

What would you do?

Contoso's migration lead reports that the customer load finished with "1,842 records created, 0 errors" and asks Maria to confirm the object as done. What should Maria do?

Key points