What is the business partner conversion (CVI) in an ECC to S/4HANA migration?

Why S/4HANA insists on a single Business Partner

ECC kept customers and vendors in separate master models, each with its own transactions, number ranges, and account groups. The same legal entity that bought from you and sold to you existed twice, with two addresses that drifted apart and two sets of tax data maintained by different teams. S/4HANA replaces that with one Business Partner carrying roles — customer, vendor, contact person, and the FI variants of each — so a single organization is a single record with as many relationships as the business needs.

The practical consequence is that the Business Partner is not optional and not deferrable. The classic customer and vendor tables remain in S/4HANA for compatibility, but they are written through BP synchronization rather than directly, and the ECC-era create and change transactions redirect to the BP transaction. Any process, interface, or custom program that assumed the old model is affected, and the conversion is where that gets surfaced.

What CVI actually does, and where it sits in the plan

Customer/Vendor Integration is the synchronization framework, and it runs in ECC — not in S/4HANA. That timing matters. For a brownfield conversion, the pre-check will not allow the technical conversion to proceed while any customer or vendor lacks a linked Business Partner, so the whole exercise is completed in the live ECC production system ahead of the cutover. It has no downtime impact on its own, which is exactly why it should be started early rather than left to the conversion weekend.

The work falls into a recognizable sequence. Each step is well-documented individually; the difficulty is that the early steps are configuration decisions the business has to own, and the late steps expose data quality that nobody has looked at in years.

• Activate CVI and decide the direction of synchronization — customer and vendor to Business Partner first, then the reverse direction once the BP is leading after conversion.
• Map account groups to BP groupings and roles, and align number ranges so that customer, vendor, and BP numbers do not collide. The 'same number' policy, where the BP inherits the customer or vendor number, is popular for a reason and fails wherever a customer and a vendor already share a number.
• Assign BP roles: general customer and vendor roles, the company-code-level FI roles, and contact-person handling, which is the part most often underestimated.
• Run the pre-checks and the synchronization cockpit, work the error log to zero, and then run a full mass synchronization with the results verified by counts and sample reads, not by the absence of red lights.

The data problems the synchronization will find

The synchronization is unforgiving in a way that the ECC master-data transactions never were. Address validation is stricter: postal codes that do not match the country format, region codes that are no longer valid, and free-text address lines that were tolerated for two decades now fail. Tax numbers get checked for format and, in many jurisdictions, for uniqueness, which is where duplicated legal entities become visible. Industry keys, transportation zones, and language keys that were never mandatory in ECC can be required by the BP role configuration.

Contact persons deserve particular attention. In ECC they were attached to the customer master with minimal validation; in the BP model each becomes a person-type Business Partner in a relationship with the organization. Estates that accumulated thousands of stale contacts — former buyers, departed accounts-payable clerks, generic mailboxes entered as people — discover that fact here, and the decision to archive or convert them is a business decision, not a technical one.

The honest posture is to treat every synchronization error as a data defect to be corrected at source. Suppressing validations to get the run to pass moves the problem into S/4HANA, where the same records will fail the first time someone tries to change them.

What breaks in custom code and interfaces

The second half of the conversion is not master data but the code and integrations that touch it. Custom programs that write to the customer or vendor tables directly, or drive the classic create and change transactions through batch input, stop working because those transactions no longer exist as targets. Inbound interfaces carrying customer or vendor creations — IDoc-based onboarding from a CRM, a supplier portal, or an acquired subsidiary's middleware — hit the same wall and need to move to the BP interfaces.

This is where reading the live system pays off. A where-used analysis across the custom code base for the customer and vendor tables and the classic maintenance transactions gives a finite, evidenced list of what must change before conversion. On a reference estate — a live ECC system used to validate this method, not a specific customer's result — that kind of analysis was part of an assessment in which roughly 44% of 356 inventoried custom objects were assessed as retirable because standard S/4HANA already delivers the capability. A customer's numbers come from their own system, but the pattern repeats: a meaningful share of the code touching customer masters exists to compensate for a limitation the BP model removes.

Sequencing, ownership, and where agents help today

Two rules keep the conversion off the critical path. First, start CVI in the opening weeks of the program, in parallel with the fit-to-standard assessment, because the data cleansing has a lead time measured in weeks to months and depends on business users who have day jobs. Second, give it a single named owner on the customer side who controls the master-data decisions — grouping design, number-range policy, contact-person archiving — rather than leaving those to an integrator who will optimize for the conversion passing rather than the model being right.

Agents are useful at the front of this work and it is worth being precise about how far that goes. Reading a live ECC system to count customers, vendors, and contact persons by account group, profile address and tax-number quality, and trace which custom objects and interfaces write to the classic tables is analytical work with verifiable output, and it is available now. Where the resulting configuration has to land in the system, the agent drafts a governed customizing transport and the customer's change board decides whether it lands — development systems only, never touching production on its own. Our functional-testing agent, which would take the converted master data through the order-to-cash and procure-to-pay flows that depend on it, is in build and design preview, not shipped. SAP describes its own direction as agent-led transformation with a claimed reduction of more than 35% in migration effort (SAP News, Sapphire 2026); that is SAP's figure, and the business partner conversion is a good place to test whether it holds, because the effort is dominated by data decisions rather than technical steps.