Data Migration & Mass Tools — Deep Guide
🎯 In plain words
🧠 The migration tools
Two tools you'll meet — one modern, one legacy:
| Tool | What it is |
|---|---|
| SAP S/4HANA Migration Cockpit | The modern tool. Run it as the Fiori app "Migrate Your Data", or classic LTMC. It ships preconfigured migration objects (material, vendor, customer, PO…) with ready-made XML / staging templates you fill in and upload. The object & structure modeller (to adjust or build objects) is LTMOM. |
| LSMW LSMW | Legacy Migration Workbench — older but still seen on real projects. Works via recording, batch input, BAPI, or IDoc. Powerful and flexible, but more manual to build than the Cockpit. |
Rule of thumb: on S/4HANA, reach for the Migration Cockpit first; use LSMW only for objects the Cockpit doesn't cover or on older systems.
🧠 Mass-change tools (after go-live)
For changing many existing records in one step:
| T-code | Mass-changes… |
|---|---|
| MM17 | Material master — change a field (e.g. purchasing group, MRP type) across a list of materials at once. |
| MEMASSPO | Purchase orders — mass-change PO fields/items. |
| MEMASSRQ | Purchase requisitions — mass-change PR fields/items. |
| XK99 | Vendor master — mass-change vendor (supplier) records. |
| MASS | Generic mass-maintenance cockpit — pick an object type, select records, change fields. |
For programmatic / repeatable loads, developers call BAPIs — e.g. BAPI_MATERIAL_SAVEDATA (create/change materials) or BAPI_PO_CREATE1 (create POs). Same data, just driven by code instead of a template.
🧠 Load order & validation
Load in dependency order — each step needs the one before it to exist:
- Org structure & config first — company codes, plants, purchasing orgs, storage locations.
- Then master data — materials, business partners (vendors/customers), purchasing info records.
- Then open transactions — open POs, open PRs, stock balances (opening inventory).
Two habits that save go-lives:
- Simulate / validate before you commit. The Cockpit (and a good LSMW build) lets you run a validation/simulation pass that flags errors before any record is written.
- Reconcile after the load. Compare record counts and key totals (e.g. number of materials, total stock value) against the source. Mind internal vs external number ranges — externally-numbered objects keep their old keys, internally-numbered ones get new SAP numbers.
🛠️ Do it now — mass-load, then mass-change
- Open the Migration Cockpit — Fiori "Migrate Your Data" or LTMC — and create a project.
- Pick the Material migration object and download its staging template (XML/spreadsheet).
- Fill in a few materials (number, description, type, base UoM, plant, purchasing group), upload, then run the validation/simulate step.
- Fix any flagged rows, then execute the load. Check the result counts.
- Now mass-change: open MM17, select those materials, and change one field for all of them (e.g. purchasing group). Execute and confirm in MM03.
- Wrong order = failed load. You can't load a material's plant view before the plant exists, or an open PO before its vendor and material exist. Load org → master data → transactions.
- Never skip simulate/validate. Always run the validation step before committing — catching errors up front is far cheaper than cleaning them out of a live system.
- Always reconcile counts & totals. A silent partial load is worse than a failed one: a failed load you notice and rerun; a half-loaded one quietly corrupts your data. Compare source vs target before you sign off.
🔗 Connects to
- Phase 3 — Master Data: materials, business partners and info records are exactly what you migrate.
- Phase 15 — SAP Activate: migration runs inside cutover, the final move from old system to live SAP.
- Material Master deep guide: know the views/fields before you map them in a template.
🎓 Cert focus & quick recall
Consultant-essential knowledge — light on the C_TS452 exam, but you will use this on every project. Know the tools and the load order.
Migration Cockpit vs LSMW?
Migration Cockpit = the modern S/4HANA tool with preconfigured objects and XML/staging templates (Fiori "Migrate Your Data" or LTMC; model objects in LTMOM). LSMW = the older Legacy Migration Workbench (recording / batch input / BAPI / IDoc) — still seen, but build it yourself.
What is MM17 for?
Mass-maintaining the material master — changing one field (e.g. purchasing group or MRP type) across many materials in a single step, instead of editing each one in MM02.
Why load org data before master data?
Dependencies. Master data references org units — a material's plant view needs the plant to exist first. Load org/config → master data → open transactions.
Why reconcile counts after a load?
To catch a silent partial load. Comparing record counts and key totals against the source confirms everything actually arrived — a half-loaded set is worse than a clean failure.
✅ You're ready to move on when…
- You can name the load order: org/config → master data → open transactions.
- You can use MM17 to mass-change a field across many materials.
- You can explain why you simulate before committing and reconcile counts afterwards.