Classic MB Transactions Replaced By MIGO
In S/4HANA, the separate classic goods movement transactions such as MB01, MB1A, MB1B, MB1C and MB31 are obsoleted in favour of MIGO, which becomes the single front end for all goods receipts, issues and transfer postings. Screen-based automation and authorizations built against the old transaction codes stop working and must be rebuilt around MIGO before conversion.
This page covers the retirement of ECC's family of separate goods movement transactions in favour of a single MIGO-based posting model in S/4HANA. It focuses on what breaks in interfaces, authorizations and user habits, and what a conversion project must inventory and rebuild before go-live rather than after.
Published 16 Sept 2026· 1,134 words
Classic ECC behaviour
In ECC, goods movements were split across a family of dedicated transaction codes, each tied to a specific business scenario. MB01 posted a goods receipt against a purchase order, MB1A posted a goods issue, MB1B handled transfer postings, MB1C covered other receipts such as initial stock upload, and MB31 posted a goods receipt against a production or process order. MBST reversed a posted material document, MB02 and MB03 changed or displayed one, and MB90 handled output processing such as pallet labels or GR slips. MIGO existed in ECC as a consolidated alternative and had been available for a long time, but a large share of customers never migrated fully, either because custom batch-input automation, authorization roles, or simple user habit remained tied to the individual MB codes. Warehouse clerks, production staff and MM users often knew only the specific transaction relevant to their task and never touched MIGO at all.
S/4HANA behaviour
MIGO becomes the mandatory single entry point for goods movements in S/4HANA. The classic MB transaction codes are treated as obsolete in the simplification of inventory management: depending on the release and the specific code, calling them either raises an error, is removed from standard menus and role templates, or is silently redirected into MIGO with the equivalent action and reference document preselected. The distinction that used to live in the choice of transaction code, purchase order receipt versus production order receipt versus plain transfer posting, now lives inside MIGO as a combination of action and reference document type on the initial screen. Configuration that governs default movement types, proposed reference documents and screen variants inside MIGO becomes the main control point instead of separate transaction-level customizing. The exact boundary of which codes are hard blocked versus merely hidden has shifted across releases, so the safe working assumption for a project is that none of the classic MB codes should be relied upon going forward, even where one still happens to execute in a given system.
Project impact
The change is felt well beyond the posting screen itself.
- Custom ABAP programs using batch input or CALL TRANSACTION against MB01, MB1A, MB1B, MB1C or MB31 fail outright because the screen sequence they recorded no longer exists or the transaction is blocked.
- Interfaces and IDoc-driven postings that were built as batch-input wrappers around these transactions break silently and are often discovered only when an overnight job that has run unattended for years produces zero postings.
- Authorization roles built around the individual MB transaction codes do not translate to MIGO's action and reference-document based authorization model, so users pass functional testing but get locked out in production because their role was never granted the equivalent MIGO action.
- Warehouse and shop-floor staff who worked from muscle memory typing MB1A or MB31 lose their entry point entirely and resist the switch during user acceptance testing.
- Output configuration tied specifically to MB90, such as pallet labels or delivery notes printed at goods receipt, does not carry over automatically and needs to be rebuilt inside MIGO's own output handling.
- Reconciliation reports and Z-queries that filter material document headers on a list of transaction codes return unexpected results because postings made through MIGO carry different reference identifiers than the old MB codes did.
Migration actions
The rebuild work has a clear order, with the inventory step acting as a hard pre-conversion gate rather than optional cleanup.
- Inventory every custom program, scheduled job, interface and IDoc mapping that issues batch input or CALL TRANSACTION against any of MB01, MB02, MB03, MB1A, MB1B, MB1C, MB31, MB90 or MBST. This must be complete before conversion, not discovered afterward.
- Rebuild each identified interface to post through the underlying API rather than screen automation. Screen-scraping against a transaction that no longer exists is the single most common cause of go-live interface failure and should not be patched, only replaced.
- Redesign authorization roles from a transaction-code model to MIGO's action and reference-document model, testing each business scenario individually rather than relying on a broad test role that masks gaps.
- Retrain warehouse, production and inventory staff on MIGO's action and reference-document selection pattern, not just on the fact that a new transaction exists.
- Reconfigure output determination for goods movement documents inside MIGO rather than assuming MB90 settings carry over unchanged.
- Explicitly script and test cancellation and reversal flows at realistic volumes, since this is the scenario most often skipped in favour of testing simple postings.
- Run at least one full period-end close in a sandbox at production-like data volumes before cutover, since batch and interface failures frequently only appear under real load.
Whose problem this is
This is a shared problem. The MM or warehouse functional lead owns the process redesign, the mapping of old transaction scenarios onto MIGO actions, and sign-off on authorization behaviour. The technical or ABAP team owns rebuilding interfaces that relied on batch input, since that automation must become API-based rather than patched. Basis or security owns the authorization role rebuild. The decision to retire rather than patch old automation belongs jointly to the technical lead and the functional owner, since patching invites recurring breakage at every future upgrade.
Common pitfalls
Several failure modes only surface after go-live, usually at the first real volume event.
- Teams confirm MIGO works in manual testing and stop there, missing that the nightly interface posting thousands of receipts through batch input against MB01 has been failing since cutover.
- Authorization testing done with broad test roles passes cleanly, then production roles built on the old transaction codes lock out real users on day one.
- Reconciliation scripts filtering material document headers on a hardcoded list of old transaction codes return no rows post go-live, and the discrepancy is initially blamed on posting errors rather than the report itself.
- Output configuration for GR slips or pallet labels tied to the old output transaction stops firing, and the gap is only noticed when the warehouse floor has no paperwork.
- Cancellation and reversal scenarios get skipped in test scripts in favour of straightforward postings, so a returns-heavy or correction-heavy month-end becomes the first real stress test of the new model in production.
- Batch automation that behaves fine in test at low volumes shows different locking or contention behaviour under concurrent production load, a difference that manual single-transaction testing never exposes.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/classic-mb-transactions-replaced-by-migoERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.