SAP · Financials · Master data

SAP Business Partner Data Migration

Migrate and convert customer and vendor master data into the SAP S/4HANA Business Partner model, including role assignment, Customer/Vendor Integration and duplicate resolution.

Discuss Your Migration All Migration Objects

Object overview

In S/4HANA the Business Partner is the single object for any party you transact with. Customers and vendors are roles on that object rather than separate masters. This is mandatory, not a design choice, and it is the item that most often surprises an ECC conversion.

The difficulty is not the model, it is what the model exposes. Customer and vendor masters were maintained separately for years by different teams under different number ranges. Merging them surfaces every duplicate party, every number-range collision and every record that was never clean enough to be merged with anything.

What data is typically migrated

Scope is agreed in discovery; this is the shape of the object.

Data area	Typical information
BP general data	Name, address, communication, BP category (person / organisation / group)
BP roles	Customer, vendor, FI customer, FI vendor and others as required
Customer role data	Company code and sales area data carried from the customer master
Vendor role data	Company code and purchasing organisation data from the vendor master
Relationships	Contact persons, has-employee, is-replaced-by and other BP relationships
Bank and payment	Bank details and payment data per role
Tax	Tax numbers and classifications

Object relationships

Dependency drives load sequence: a child cannot exist before its parent.

Business Partner

└─ BP role: customer

└─ Company code data

└─ Sales area data

└─ BP role: vendor

└─ Company code data

└─ Purchasing org data

└─ BP relationships → contact persons

└─ Bank details / tax numbers

Object migration flow

Source Business Partner→DataMove→Map & transform→Validate→SAP Business Partner→DataVault reconciliation→Sign-off

Before you migrate this object

Confirm each of these before the first migration cycle.

□BP groupings and number ranges are configured

□Role definitions and CVI mapping are set up

□Duplicate matching rules are agreed with the business

□The expected merge reduction is estimated and accepted by finance

□Check-table values exist for every country, region and account group in scope

□Parties that are both customer and vendor are identified

Common source systems

Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.

SAP ECC Production-provenSAP R/3 SupportedOracle EBS SupportedOracle JD Edwards SupportedMicrosoft Dynamics 365 Supported

Source-to-target mapping examples

Object-level equivalence. Field-level mapping is produced per engagement.

Source system	Source entity	Target object
SAP ECC	Customer master (KNA1/KNB1/KNVV)	Business Partner + customer role
SAP ECC	Vendor master (LFA1/LFB1/LFM1)	Business Partner + vendor role
Oracle EBS	Supplier / Customer	Business Partner + relevant role
JD Edwards	Address Book (F0101)	Business Partner

Migration methods for this object

Customer/Vendor Integration (CVI) for in-place ECC to S/4HANA conversion

SAP Migration Cockpit business partner migration object for greenfield loads

Number range and grouping configuration agreed before either approach

Extraction considerations

Both masters, togetherCustomers and vendors are extracted as one exercise because they converge. Treating them as two unrelated objects defers the duplicate problem to load time.

Parties that are both customer and vendorThese already exist in most estates and become one BP with two roles. Identifying them before conversion is what prevents duplicate BPs.

Number rangesCustomer and vendor number ranges frequently overlap. Whether BP numbering is internal, external or grouping-driven is decided before extraction because it determines the key strategy.

Contact personsLegacy contact person records become BP relationships rather than attributes, and are extracted as their own set.

Transformation rules

Party de-duplication and mergeThe defining transformation. Matching on tax number, name and address, with the merge decision recorded so it can be audited.

Role derivationWhich BP roles each party receives, driven by whether it had customer data, vendor data or both.

Grouping and number assignmentBP grouping determines the number range; the legacy key is retained where the grouping permits external numbering.

Company code and org data by roleCarried into the role-specific segments rather than onto the general BP.

Data quality and validation

BP category correct

Person, organisation or group, which cannot be changed after creation.

Required roles present

A party with open payables needs the vendor role; open receivables need the customer role.

Number range collision check

Before assignment, not after.

Duplicate detection

On tax number, name and address, run before load.

Check-table validity

Country, region, industry, account group and payment terms all validate against configuration.

Load sequence and dependencies

What has to exist before this object can load.

1Configuration: BP groupings, number ranges, role definitions, CVI mapping
2Reference data and check tables
3Business Partners (general data)
4Customer role data
5Vendor role data
6BP relationships and contact persons
7Bank details and tax numbers

Common migration errors

What actually fails on this object, and why.

Duplicate business partnerTwo source records for the same party, the single most common failure on this object.

Number range collisionThe assigned BP number is already in use or falls outside the grouping's range.

Missing role for an open itemAn open payable references a party without the vendor role.

Invalid BP categoryA person record classified as an organisation or vice versa, which cannot be corrected in place.

Check-table rejectionCountry, region, industry or account group value not present in configuration.

CVI mapping incompleteThe customer or vendor has no BP mapping entry after conversion.

Reconciliation

Counts alone rarely prove this object migrated correctly.

BP count: expected to be lower than customers plus vendors, because duplicates merge — the expected reduction is agreed in advance, not discovered

Role coverage: every party with open AP has the vendor role, every party with open AR has the customer role

Duplicate merge log reconciled: source records in, surviving BPs out, merges recorded

Company code and sales area segment counts per role

Open item resolution: every open AP and AR item resolves to a BP

How Syntra ETL supports this object

DataMove

Extraction, mapping, transformation, validation preparation and target load generation.

Explore DataMove →

DataVault

Preserves source, prepared and target states for reconciliation, lineage and audit evidence.

Explore DataVault →

DataLens

Migration progress, data quality, exceptions and readiness across cycles.

Explore DataLens →

Relevant migration routes

Source-specific guidance for moving this object.

SAP ECC→SAP S/4HANA

Successfully delivered projects involving this object

Published case studies whose scope included business partner.

SAP ECC→SAP S/4HANANetherlands-Based EnterpriseEnterprise · Europe

SAP ECC Source platform
SAP S/4HANA Target platform
Multi-cycle Controlled migration cycles

Critical SAP data transitioned to S/4HANA with greater cutover confidence through repeatable migration cycles.MIGRATION COMPLETEView Project →

Frequently asked questions

Why is Business Partner conversion mandatory in S/4HANA?

Because S/4HANA uses the Business Partner as the single object for any transacting party. Customers and vendors become roles on it, and the separate customer and vendor masters are no longer maintainable as independent objects.

What happens to a party that is both a customer and a vendor?

It becomes one Business Partner carrying both roles, with the company code and organisational data preserved under each role. Identifying these parties before conversion is what prevents them arriving as two separate BPs.

How are duplicate customers and vendors handled?

They are matched before conversion on tax number, name and address, and the merge decision is made by the business and recorded. Merging after conversion is far more expensive because transactional data already references the wrong BP.

Should the BP count equal customers plus vendors?

No — it should be lower, because duplicates merge. The expected reduction is estimated during profiling and agreed with finance, so reconciliation compares against an expected figure rather than a simple sum.

Planning a similar data migration?

Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.

Discuss Your Migration Explore Migration Routes