ERP, PIM and OMS Integration During B2B Migration

Ask five teams where a product’s price lives and you may receive five answers. The ecommerce team points to the storefront. Finance cites ERP. Merchandising says PIM. Sales produces a negotiated contract. The customer sees one number in a cart and another on the invoice.

That disagreement is inconvenient in everyday operations. During an enterprise B2B ecommerce migration, it is dangerous. New APIs may move data faster while reproducing every ambiguity in the old system. An integration that is technically successful can still send a perfectly formed, commercially incorrect order.

The first architecture decision should therefore be about authority, not middleware. Before comparing integration platforms, define which system is allowed to create or change each business fact, how consumers learn about updates and what happens when messages arrive late, twice or not at all.

This article provides a working model that enterprise teams can adapt. It is not a universal blueprint: the correct owners depend on the retailer’s operating model, contracts and systems. The value lies in making those choices explicit and testable.

The source-of-truth matrix comes before the API map

A source of truth is the system whose value wins when two systems disagree. It is not necessarily the system that displays the data or receives the most requests.

Data or event	Common candidate owner	Critical consumer	Typical failure during migration
Product attributes	PIM	Storefront, search, marketplaces	Variant or unit-of-measure mismatch
Contract pricing	ERP or dedicated pricing engine	Checkout, quoting, billing	Buyer sees an unapproved price
Available-to-promise inventory	Inventory/OMS layer	Checkout, allocation, store systems	Oversell or rejected fulfillment
Order lifecycle	OMS	Warehouse, support, customer app	Order accepted but never released
Financial posting	ERP or finance ledger	Accounting and tax	Duplicate invoice or missing credit
Payment authorization/capture	Gateway and payment orchestration	OMS, finance, customer support	Repeated capture or orphaned authorization
Identity and purchasing role	IAM / B2B account service	Commerce, approvals, procurement	Unauthorized buyer places an order

These are candidates, not fixed industry laws. Some companies manage pricing in commerce, some in ERP; some OMS products own reservations, others consume an inventory service. The job is to select an owner and publish the exception rules.

Add three fields to the matrix: the identifier shared across systems, the allowed direction of change and the accepted staleness window. “Sync inventory in real time” is not a specification. Does “real time” mean 200 milliseconds, 30 seconds or eventual consistency with a safety buffer? Can the customer reserve the last unit if one store is offline? What evidence proves the answer?

An integration contract needs seven clauses

Documentation that says POST /orders is not enough. For every important integration, require a short contract with seven clauses.

1.  Purpose and owner. Which business capability does the interface serve, and who owns the decision it enables?

2.  Identity and correlation. Which customer, account, order and transaction IDs survive migration? How is an old identifier mapped to a new one?

3.  Schema and versioning. Which fields are mandatory, which changes are backward-compatible and how will consumers be warned?

4.  Delivery behavior. Is the interface synchronous, asynchronous, batched or mixed? What are its ordering and retry expectations?

5.  Idempotency and side effects. What prevents the same business intent from executing twice, especially for payments and fulfillment?

6.  Failure policy. Where do invalid messages go? Who receives an alert? How is recovery recorded and replayed?

7.  Reconciliation and audit. Which totals, counts and exceptions prove that the integration produced the correct business state?

The contract must be signed off by both producer and consumer teams, plus the relevant business owner. If warehouse, finance and commerce each assume that someone else will handle a failed callback, the interface has no real owner.

Synchronous does not always mean safer

Architects often want every call to return a definitive answer immediately. That is reasonable when checkout needs to confirm buyer eligibility or price. It becomes risky when a synchronous request chains storefront, ERP, tax, payment, fraud, OMS and warehouse systems into one path. Each new dependency adds latency and another way to fail a customer’s purchase.

Use synchronous requests for decisions that truly must be known before the customer can proceed. Use event-driven flows for downstream activities that can be tracked through explicit states. For example, an order may be accepted, then allocated, then released for fulfillment. Those statuses should not be collapsed into one ambiguous “success.”

Events improve decoupling, but they demand discipline. Message brokers can redeliver events. Consumers can restart. A payment webhook can appear after an order cancellation. Design for duplicate and out-of-order delivery using stable transaction identities, state machines, idempotent handlers and dead-letter/recovery workflows.

Where an application writes a database record and publishes an event, consider patterns such as a transactional outbox so that the record and its publication intent cannot silently diverge. The exact implementation depends on the database and infrastructure, but the business invariant does not: an accepted order must not disappear between two systems.

Build a migration-specific exception ledger

A reconciliation dashboard that shows “99% green” is not enough for enterprise commerce. The finance controller needs to know whether the exceptions concern missing thumbnails or unsettled funds. An operations manager needs to identify stuck orders before customers call.

Create an exception ledger that stores the business ID, source system, target system, expected state, observed state, discrepancy category, owner, remediation action and resolution timestamp. Populate it from automated comparisons rather than relying on manual spreadsheet checks.

Set separate severity rules for money, identity, permissions, inventory, tax and non-critical metadata. Money and access-control differences should generally halt a relevant migration wave until resolved. Cosmetic catalog differences might be safely queued for correction. The important part is making this an agreed release policy rather than a judgment made during an incident.

A worked example: a contract-price mismatch

Consider a multinational B2B distributor moving from a custom portal to a managed commerce platform. The buyer has a negotiated price in ERP, a promotional display price in commerce and a currency conversion rule shared with billing. During staging, the target commerce API returns the promotion while invoice generation applies the contract rate.

The API calls are all successful. Unit tests for the separate systems pass. The purchase is still wrong.

The cure begins by declaring the precedence rule. If contract terms override promotions for that account, the pricing service should enforce it at quote and order acceptance, not hope that finance corrects the invoice later. A canonical price decision should carry account ID, contract version, currency, effective date and an auditable reason code. Test the rule against actual historical edge cases with sensitive data removed.

That example is illustrative, not a report of a specific company’s incident. It demonstrates why integration coverage must include business-rule parity, not just transport reliability.

The cutover sequence: history, delta, authority, retirement

An enterprise migration becomes manageable when each phase has its own acceptance test.

1. Historical baseline. Export and load customers, products, account structures and historic orders. Validate referential integrity, totals and permissions. Keep a source-to-target ID map in a controlled repository.

2. Live delta. Capture changes created after the baseline. Choose event capture, CDC or controlled batch synchronization based on freshness and system constraints. Verify replay and deduplication.

3. Shadow comparisons. Compare safe read-side results and sandbox transactions. Do not execute the same live payment or procurement instruction twice just to prove parity.

4. Controlled authority switch. Move one channel, account segment or capability at a time where feasible. Only one system should be authorized to commit each critical business action. Make the route reversible unless a documented data-state boundary has been crossed.

5. Reconciliation and retirement. Keep the legacy path until transaction counts, financial states and downstream acknowledgments meet agreed criteria. Then decommission unused integrations deliberately. A dead connector left running can create phantom updates months later.

Shopify’s B2B replatforming guidance highlights how ERP, customer data, pricing and fulfillment integration must be understood before migration. The point extends beyond Shopify: a platform’s API coverage is not evidence that a customer’s commercial rules have been preserved.

What a useful B2B migration case actually demonstrates

In a publicly documented Salesforce B2B Commerce marketplace migration, Zoolatech describes moving a PHP/Laravel-based marketplace while building integrations and automation around finance, tax, punch-out procurement and order approvals. The published case identifies historical records migrated through automated pipelines, including customers, manufacturers, orders and products. It also reports $2,000+ in monthly savings from accounting and tax automation and faster feature delivery compared with the previous vendor.

Those details matter because they show why migration is not a website-copying exercise. The new commerce engine required extensions for workflows that were not fully supported by native platform features. Historical-data migration, commercial rules and integrations belonged to the same transformation.

The case cannot tell another retailer exactly which middleware to buy; its practical lesson is the need for a tested ownership and integration plan. Teams evaluating enterprise ecommerce migration services should demand that plan before accepting a launch date.

Five questions to put in the RFP

Which system wins when prices disagree? Ask for a specific answer covering promotions, customer contracts, taxes and currency. “We will synchronize it” is not enough.

What is the delivery contract for an accepted order? Require correlation IDs, ownership and a recovery path for events that fail after payment.

How will historical accounts retain their roles? B2B buyers, approvers and procurement integrations need authorization tests, not only successful sign-in.

What does reconciliation look like during the first 72 hours? Ask to see the exception ledger and responsible operators.

When can legacy integrations be switched off? Require a measurable retirement gate, not an arbitrary calendar date.

The best migration architecture is usually less glamorous than the platform demo. It makes invisible commercial rules visible and assigns an owner to every state transition. That is the work that keeps a new storefront from producing old operational failures at higher speed.

FAQ

Should ERP or the ecommerce platform own pricing?

Either can, depending on the business model. The essential requirement is a documented precedence rule for contractual, promotional and regional pricing, backed by tests and financial reconciliation.

Can PIM and OMS data be migrated in one batch?

Historical data may be loaded in batches, but live changes still require a controlled delta strategy. Orders, inventory and account changes cannot simply be frozen indefinitely in an operating business.

Is real-time integration always necessary?

No. Some workflows need synchronous answers; others tolerate bounded delays. Define the staleness window and failure behavior per capability rather than calling every integration “real time.”

What proves a B2B ecommerce integration is production-ready?

Versioned contracts, end-to-end transaction tracing, idempotency tests, reconciled financial and inventory states, a support owner and a tested recovery procedure are stronger evidence than a successful API demonstration.