The Migrate Your Data app: projects and objects

The data migration fundamentals course introduced the SAP S/4HANA Migration Cockpit as SAP's tool of choice for loading data into a new SAP S/4HANA system. This course gets hands-on with its most widely used approach: migrating data using staging tables, filled either from the cockpit's file templates or by your own extraction tools. We follow Contoso Motor Co.'s Wave 2. Contoso's own move from SAP ECC was a system conversion, so its existing data never needed loading. Right after the conversion, Contoso acquired Alternadores del Norte S.A. de C.V. in Monterrey, Mexico, which runs a non-SAP legacy ERP. Its data is loaded into the converted SAP S/4HANA system as new company code 1910 (currency MXN) with plant 1910 Monterrey: suppliers, products, purchasing info records and open purchase orders. That is a new-implementation-style load into an existing system, and exactly what the staging table approach is for.

Where you work

You work in the SAP Fiori app Migrate Your Data – Migration Cockpit. Access needs the authorization for the app plus authorizations for the business data each migration object creates. In older on-premise releases the cockpit was transaction LTMC; in current releases the Fiori app replaces it, and projects created in LTMC are not opened in the new app. Everything in this course applies to SAP S/4HANA 2025 on-premise and Private Edition; Public Edition uses the same app with a smaller, cloud-specific set of objects and settings.

Creating a migration project

Work is organized into migration projects. A project holds the migration objects you need, their staging tables, mapping values, run history and messages. When you create a project with the staging table approach, you decide:

• Project name: Contoso uses one project per load wave, for example W2 1910 Mock 2 Master Data, so that runs and messages are not mixed between mocks.
• Database connection: the staging tables live either in the local SAP S/4HANA database schema, or in a remote SAP HANA schema reached through a database connection. Local is the default; remote suits teams whose own ETL tooling fills the tables.
• Migration objects: chosen from the list of predefined objects, such as Bank, Supplier, Customer, Product, Purchasing info record and Purchase order (open items). Object names vary by release; read them in your system.

What a migration object is

A migration object is SAP's predefined package for one type of business data: its source structures (what you provide), its target structures and the standard SAP interface it uses to create the data, with the same checks as the normal application. Each object has documentation in the app that explains the required fields, the prerequisites (configuration and predecessor objects), how to validate the result in the business apps, and any restrictions. Read it before you build anything; it answers most "why did this fail?" questions in advance.

Dependencies drive the object list

Objects depend on each other. A purchasing info record needs the supplier and the product; an open purchase order needs both plus the info record if prices come from it. The cockpit shows predecessor objects, and the load must respect them. The Wave 2 Mock 2 master data project contains Bank, Supplier, Customer and Product; a second project for dependent master data contains Purchasing info record and Source list; a third, for open items, follows later in the cutover sequence.