SD / O2Carchitect

SD Customer and Business Partner Part 5: BP Governance — Migration Strategy, MDG and Multi-System Consolidation

Key takeaway

Architect's view of the Business Partner as the enterprise master data object: ownership and data standards, duplicate prevention, migration strategy (greenfield load vs brownfield conversion), SAP MDG for central governance, replication to other systems, and consolidating customers from several ERPs.

Explanation

📌 KEY POINTS
✅ BP governance defines who owns which data (general, FI, sales), the standards (naming, address, tax) and the approval process.
✅ Migration: greenfield loads BPs with the S/4HANA migration cockpit; brownfield converts existing customers/vendors via CVI before the technical conversion.
✅ SAP MDG (Master Data Governance) adds workflow-based creation/change requests, duplicate checks and replication (DRF) to connected systems.
✅ Consolidation from several ERPs needs matching and merging into golden records, with key mapping to legacy numbers.
⚠️ Without governance, S/4HANA simply collects duplicates faster — BP does not clean data by itself.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–4 covered data structure, configuration, partners and CVI. This part is the enterprise view.

━━━━━━━━━━━━━━━━━━━━
▶ 1. OWNERSHIP AND STANDARDS

General data: central master data team.
Company code data: finance (reconciliation account, payment terms, dunning).
Sales area data: sales operations (pricing procedure, shipping, billing data).
Standards: legal name, address validation, tax number formats, search terms.

━━━━━━━━━━━━━━━━━━━━
▶ 2. DUPLICATE PREVENTION

Duplicate check on creation (address/tax number matching, e.g. with SAP address services or MDG matching).
One BP per legal entity; ship-to locations as separate BPs linked via partner functions.
Periodic duplicate reports and merge process.

━━━━━━━━━━━━━━━━━━━━
▶ 3. MIGRATION STRATEGY

Greenfield: migration cockpit objects for customer/BP with cleansed source data.
Brownfield: CVI conversion of all customers and vendors as a pre-conversion step (Part 4).
Selective data transition: move chosen company codes and their partners.
Key mapping legacy number ↔ BP number for interfaces and history.

━━━━━━━━━━━━━━━━━━━━
▶ 4. SAP MDG

Central governance hub (hub or co-deployed): change requests, approval workflow, validations, duplicate checks.
Data replication framework (DRF) distributes BPs to S/4HANA, CRM, other ERPs.
Consider MDG when several systems consume BP or regulatory requirements demand audit trails.

━━━━━━━━━━━━━━━━━━━━
▶ 5. MULTI-SYSTEM CONSOLIDATION

Load from several ERPs, match, choose survivors, create golden records.
Map each legacy customer to the golden BP (key mapping).
Align partner hierarchies (sold-to/ship-to) and sales area extensions to the template.

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

Define data ownership per data level and data standards.
Decide duplicate-check approach and merge process.
Choose migration path (migration cockpit, CVI conversion, selective transition).
Decide on MDG based on number of consuming systems and compliance needs.
Set KPIs: duplicates, incomplete BPs, time to create.

✅ CHECKPOINT: every BP field has an owner and every creation path goes through the same checks.

Code example

ABAP Code

===== STEP 1: ownership matrix =====Data level          | Owner                 | Approver        | Key checksGeneral (BUT000)    | Master data team      | MD lead         | legal name, address validation, tax no.Company code (KNB1) | Finance AR            | AR lead         | recon account, payment terms, dunningSales area (KNVV)   | Sales operations      | Sales ops lead  | pricing proc., shipping cond., Incoterms ===== STEP 2: migration paths =====Greenfield  : S/4HANA Migration Cockpit (LTMC/"Migrate Your Data" app) object "Customer" / "Business partner"Brownfield  : CVI conversion via MDS_LOAD_COCKPIT before system conversionSelective   : data transition service for chosen company codes ===== STEP 3: MDG flow (MDG-C / BP) =====Change request → validation + duplicate check → approval workflow → activation → DRF replicationReplication targets: S/4HANA clients, CRM, legacy ERPs, data lake ===== STEP 4: KPIs =====Duplicate rate | % BPs with incomplete sales area data | average creation lead time | PPO open entries

Real project scenario

A group running three regional ERPs moved to one S/4HANA system. The initial plan migrated all 1.2 million customers 1:1 from each ERP. A matching pilot showed 22% overlap — the same legal entities existed in two or three systems with different numbers and terms. The architect changed the approach: consolidation with matching rules on tax number and normalized address, golden records with survivorship rules, key mapping tables for interfaces, and SAP MDG as the single creation channel after go-live. The migrated volume dropped to 640,000 BPs and billing disputes caused by conflicting payment terms fell sharply after the first quarter.

Common mistakes

Migrating customers 1:1 from each source system without matching.
No owner for company code or sales area data after go-live.
Several creation channels (BP transaction, interfaces, MDG) with different checks.
Creating a new BP for every ship-to address instead of linking via partner functions consistently.
Introducing MDG without defining data standards first.

Best practices

Define ownership, standards and duplicate rules before migration.
Consolidate and create golden records when merging systems.
Keep one controlled creation channel with the same validations.
Maintain key mapping for legacy numbers.
Track master data KPIs continuously.

Interview angle

Questions: "How would you govern BP data in a global S/4HANA landscape?", "When do you recommend SAP MDG?", "How do you migrate customers from several ERPs?"
Strong answer: ownership per data level, standards and duplicate checks; migration via migration cockpit (greenfield), CVI conversion (brownfield) or selective transition; MDG for workflow, validation, duplicate check and DRF replication when several systems consume BP or compliance requires it; consolidation with matching, golden records and key mapping.

Practice this lesson

Quick check

1. When is SAP MDG for business partner most clearly justified?

2. Who should typically own company code data (reconciliation account, payment terms, dunning) of a business partner?

3. A group consolidates customers from three ERPs into one S/4HANA system. Which approach avoids importing the same legal entities several times?

Interview questions

1. Multiple regional teams independently maintain customer master records, resulting in duplicate customers and inconsistent sales area data. What governance approach would you recommend using MDG or Business Partner controls?

Answer it in your own words first, then compare.

2. Your organization uses SAP MDG to govern customer master creation, but sales teams complain that newly approved customers cannot be used in sales orders for two days after MDG approval. How would you investigate and resolve this?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.