skill4sapBusiness Partner conversion gets a line or two in most migration overviews: customers and vendors become Business Partners, SAP provides conversion programs, move on. In practice, BP conversion is one of the more technically involved parts of a conversion project, with its own data model, its own synchronization architecture, and its own well-documented failure modes. Teams that treat it as a scheduling checkbox rather than a data remediation project are disproportionately represented among the go-lives that slip.
1Why Business Partner Exists as a Concept
In ECC, customer master data (tables KNA1, KNB1, KNVV and others) and vendor master data (LFA1, LFB1, LFM1 and others) were separate objects with separate maintenance transactions (XD01/XD02/XD03 for customers, XK01/XK02/XK03 for vendors). A given real-world business partner who was both a customer and a vendor to your organization — common in retail and manufacturing — existed as two entirely separate, unlinked records.
S/4HANA consolidates this into a single Business Partner object (table BUT000 and its related tables) that can carry one or more roles — customer, vendor, or both — against one underlying identity. This is not a cosmetic renaming; it is the same architectural philosophy behind the Universal Journal, applied to master data: one record, multiple roles, instead of multiple disconnected records that have to be manually kept in sync.
2CVI: The Synchronization Layer That Makes This Work
Customer/Vendor Integration (CVI) is the framework that keeps the classic customer and vendor tables and the new Business Partner tables synchronized during the transition. Even after going live on S/4HANA, many organizations continue using classic transactions and classic tables in reports and interfaces for some period — CVI is what makes a change made through the Business Partner transaction (BP) correctly populate the equivalent classic tables, and vice versa, until everything is fully cut over to BP-first processes.
CVI isn't a one-time conversion program — it's an active, ongoing integration layer with its own configuration (customer and vendor number ranges mapped to BP groupings, role determination rules, and field mapping configuration in transaction BP's customizing). Misconfigured CVI mapping is one of the most common post-go-live support tickets: a field updated in the classic transaction doesn't show up correctly in the BP record, or a new customer created through an interface doesn't get the expected BP role assigned, because the mapping and role-determination rules weren't fully tested against every creation path the business actually uses — not just the manual transaction.
- CVI synchronizes classic customer/vendor tables with Business Partner tables — it is not removed after go-live, it keeps running
- Number range mapping between customer/vendor numbers and BP numbers must be configured and tested before conversion, not during
- Every creation path (manual transaction, interface, batch load, IDoc) needs its own test of correct BP role assignment
- Field mapping customizing in BP determines what data flows where — misconfiguration here is the most common post-go-live BP support issue
3The Pre-Conversion Data Cleanup That Actually Matters
The conversion programs (commonly referenced as the FLBPD1/FLBPD2/FLBPD3 family of Business Partner conversion tools, or their newer Business Partner Conversion Cockpit equivalents) will technically process almost any customer and vendor master data you feed them — the programs rarely fail outright. The risk is that they produce BP records that are technically valid but functionally wrong, because the source data had problems the conversion programs are not designed to detect.
Duplicate detection is the single highest-value cleanup activity before conversion. If the same real-world entity exists as multiple customer or vendor numbers in ECC — common after mergers, acquisitions, or simply years of decentralized master data creation — the conversion will typically create separate Business Partner records for each, carrying the duplication forward into the new system rather than resolving it. Post-go-live BP de-duplication is possible but significantly more disruptive, since open transactions, credit management data, and partner functions all have to be re-pointed to the surviving record.
Incomplete address and tax data is the second major source of post-conversion issues, particularly for organizations operating across multiple countries with different tax ID formats and address validation rules. The Business Partner model is stricter about structured address data than the classic customer/vendor masters were in practice, even where the field-level requirements were technically the same — inconsistent historical data entry that classic transactions tolerated can surface as hard validation errors in BP maintenance after conversion.
- Run duplicate detection and resolution before conversion — post-go-live de-duplication requires re-pointing open transactions and is far more disruptive
- Audit address and tax data completeness against BP's stricter validation rules, not just against the classic transaction's historical tolerance
- Reconcile partner function assignments (ship-to, sold-to, bill-to, payer) before conversion — these map to BP relationships and are easy to lose track of in bulk conversion
- Test the full conversion against a realistic data volume in a sandbox, not a small sample — duplicate and data-quality issues often only surface at scale
4Where This Shows Up After Go-Live
The most common post-go-live symptom of incomplete BP preparation is a support ticket volume spike around master data maintenance — users who could previously update a customer or vendor record in one transaction now hit role-determination errors, missing fields, or unexpected validation failures in the Business Partner transaction, because the underlying CVI configuration or data quality issue wasn't caught during testing.
The second common symptom is interface failures — inbound integrations (EDI, IDocs, API calls from e-commerce or procurement platforms) that create or update customer and vendor records were built against the classic data model's assumptions, and need to be re-validated against the Business Partner role-determination logic, not just re-pointed at new table names. Interfaces are a frequent blind spot specifically because they're not part of anyone's manual testing script — they only get exercised when a real transaction comes through, sometimes for the first time in production.
Key Takeaway
Business Partner conversion is a data remediation project with its own architecture, not a conversion program you run once during the technical cutover. The organizations that go live cleanly are the ones that treat CVI configuration, duplicate resolution, and interface validation as workstreams with dedicated testing time — not line items inherited by default inside the broader technical conversion plan. The paragraph in most migration overviews undersells exactly how much of a go-live's actual risk lives here.