User Exits Part 2: User Exits vs Customer Exits vs BAdIs — When to Migrate

📌 KEY POINTS
✅ User exits: FORMs with full access to global data; customer exits: function modules with fixed parameters; BAdIs: interfaces with classes, filters and multiple implementations.
✅ Migration is worth it when an exit is overloaded, hard to test, shared by many teams or blocks clean-core goals.
✅ Often the best first step is refactoring: keep the exit as entry point and move the logic into classes.
⚠️ Moving logic to a BAdI that runs at a different time or with less data can change behaviour — compare carefully.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 introduced user exits. Before diving into specific includes, compare the technologies — you will meet all three.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CUSTOMER EXITS IN BRIEF

• SAP code: CALL CUSTOMER-FUNCTION '001' → FM EXIT_SAPMV45A_001 (example pattern).
• SMOD: shows enhancements and components (function exits, screen exits, menu exits).
• CMOD: your project; code goes into the ZX… include inside the exit FM; activate the project.
• Only one project can use an enhancement.

━━━━━━━━━━━━━━━━━━━━
▶ 2. COMPARISON

• Data access: user exit — all globals; customer exit — parameters only; BAdI — parameters/objects only.
• Implementations: user exit — one code block; customer exit — one project; BAdI — one or many, with filters.
• Testability: user exit — hard; customer exit — medium; BAdI — good (classes).
• Upgrade: all stable, BAdIs cleanest; user exits need an access key.
• S/4HANA: all three still exist on-premise; released BAdIs are the clean-core option.

━━━━━━━━━━━━━━━━━━━━
▶ 3. WHEN TO KEEP A USER EXIT

• SAP offers no BAdI at that point (common in SD save logic).
• Logic is small, documented and stable.

━━━━━━━━━━━━━━━━━━━━
▶ 4. WHEN TO MIGRATE OR REFACTOR

• The exit contains hundreds of lines from several projects.
• A released BAdI for the same purpose exists (check in S/4HANA).
• Multiple countries need different logic (filters would help).
• Business wants unit tests or reuse from Fiori/OData.

━━━━━━━━━━━━━━━━━━━━
▶ 5. HOW TO MIGRATE SAFELY

1. Inventory what the exit does (per requirement).
2. Check timing and data of the target BAdI (debug both).
3. Move logic into classes first, still called from the exit.
4. Switch the call to the BAdI implementation; remove it from the exit in the same transport.
5. Regression test dialog, BAPI and IDoc paths.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. SMOD: display enhancement V45A0002 and its components.
2. Compare MV45AFZZ USEREXIT_SAVE_DOCUMENT_PREPARE with an available sales BAdI in your release (timing, parameters).
3. Write a migration decision for one exit using the criteria above.

✅ CHECKPOINT: you can compare the three technologies and decide whether to keep, refactor or migrate an exit.

MV45AFZZ in a global template had grown to 3,000 lines from seven projects, and every change needed a full SD regression test. The team did not migrate everything at once: they moved each requirement into a class, called from the same exit, with unit tests.
When the company moved to S/4HANA, five of the classes were connected to released sales BAdIs without rewriting the logic; the rest stayed in the user exit with documented reasons.

• Big-bang migration of all exits.
• Assuming a BAdI runs at the same time with the same data.
• Duplicating logic in exit and BAdI during migration.
• Forgetting to activate the CMOD project.
• No regression tests for BAPI/IDoc paths.

• Refactor logic into classes first.
• Compare timing and data before switching technology.
• Move and remove in the same transport.
• Keep a register of exits, owners and requirements.
• Prefer released BAdIs where they exist in S/4HANA.

Questions: "User exit vs customer exit vs BAdI?", "Would you migrate user exits to BAdIs?", "How do you implement a customer exit?"
Strong answer: user exits are FORMs with global access, customer exits are EXIT_ FMs via CALL CUSTOMER-FUNCTION implemented in ZX includes and activated in CMOD, BAdIs are OO with filters and multiple implementations; migrate when overloaded or when released BAdIs exist; refactor to classes first, check timing/data, test all paths.