Don’t underestimate integration. Everyone does.

Integration is where good projects go wrong

Digital transformation projects often fail because integration was scoped like a plugin when it needed to be treated as a programme of work.

At the platform selection stage, everything looks reassuring. There’s a connector. There’s an API. The demo shows orders flowing cleanly from basket to backend. It feels manageable.

That early reassurance is where integration gets underestimated.

A connector means two systems can exchange data. It doesn’t mean your operational logic translates cleanly between them. Your ERP might apply a 15% discount to Customer X based on annual volume, a manual override from 2019, and a regional sales agreement that was never documented. The connector can pass the final price through. It can’t encode the reasoning behind it.

Contract pricing, warehouse allocation rules, finance approval steps, and customer-specific agreements all need to be defined, mapped, and tested.

Integration surfaces the workarounds your business has been carrying quietly. Spreadsheets fill data gaps. Manual adjustments. Customer agreements in inbox threads. Once systems connect, those grey areas need to be structured.

When your sales team maintains a spreadsheet of customer-specific packaging requirements because the ERP doesn’t have that field, integration forces a decision: extend the data model, build override logic, or tell sales that information can’t flow online.

When that work isn’t scoped early, it reappears as extended timelines, unexpected change requests, and reconciliation issues that erode confidence. By the time concern becomes visible, the budget has already moved.

If you’re scoping or budgeting now, integration needs the same depth of thinking as platform selection.

Who this hits hardest

If you’re an IT director, platform owner or digital lead, integration risk sits with you.

You shape scope, validate numbers, and explain variance when forecasts shift. You’re balancing commercial pressure with technical constraint. The board wants progress. Sales want capability. Operations want stability. Finance wants predictability.

A connector creates a quiet assumption that integration is handled. That assumption shifts risk into delivery, where it’s harder and more expensive to address. At the planning stage, integration appears as a timeline dependency rather than a discipline requiring design. An API or certified module suggests that the difficult thinking is done.

Delivery reveals the gaps.

Your ERP behaves differently from the demo. Your PIM structure doesn’t reflect buying behaviour. Pricing logic built over years needs to be translated into explicit rules. What felt manageable expands under build conditions.

Manufacturers, wholesalers and distributors carry layered complexity. Customer-specific pricing. Discount hierarchies. Multi-warehouse fulfilment. Credit rules shaped by experience. Once systems connect, each needs to be coordinated.

Discovery during build is expensive because change happens when teams are committed. Developers revise partially-built integrations. Data teams re-map fields. Business teams rewrite test scenarios. The same rule that takes a day to document in planning takes a week to implement mid-build, plus rework.

The assumption: Out-of-the-box equals low effort

“Out of the box” reshapes expectations.

For vendors, it signals compatibility. There’s a supported connector and documented integration path. That doesn’t account for operational alignment.

A connector doesn’t guarantee the presence of structured data. It doesn’t reconcile pricing logic split across systems. It doesn’t resolve differences between your internal categorisation and how customers buy.

The effort sits in that gap.

When budgeting anchors to connector availability, integration feels predictable. Vendors address common patterns. Your business carries specific decisions shaped by history and customers. Workarounds exist. Approval flows reflect organisational dynamics.

If the scope reflects connector presence rather than operational reality, the budget assumes simplicity. Adjustment happens later, when change is costly.

Integration is a programme of work

Platform demos present integration as a capability. A badge in a comparison table. A clean system diagram.

In practice, it influences core operations.

Connecting commerce to ERP defines how orders are created, priced, validated and fulfilled. It determines where customer data is mastered. It formalises credit logic. It shapes stock exposure across warehouses.

Data ownership means defining which system is authoritative. If a customer’s credit limit appears in both ERP and commerce, which is correct when they differ? Who can change it? How does the other system learn? Without clear answers, you have two customer records that drift.

These are operational decisions with commercial consequences.

When PIM is included, structural choices become visible. Product hierarchies, variant handling, and data quality directly shape buying experience.

Integration requires decisions about where rules live and who governs them. That work touches process, data and people simultaneously.

A programme means dedicated budget, named leadership, cross-functional workshops, phased delivery, and governance for changes. It requires deliberate planning, clear ownership and realistic timelines.

Without that structure, alignment happens reactively during build, when everyone’s under pressure.

ERP and PIM: Where complexity compounds

When ERP and PIM are both in scope, integration becomes coordination between systems that were never designed to agree.

ERP represents how the business runs. Orders, pricing, stock, credit control and fulfilment rules reflect decisions made over years. Some documented. Some institutional knowledge.

Connecting commerce requires that logic to be explicit.

Customer pricing must calculate reliably online. Credit thresholds need defined approval paths. Stock needs consistent representation. Allocation and backorder behaviour must be predictable.

Building reliable ERP integration requires addressing these dependencies during planning and design.

PIM introduces structural dependency. Internal categorisation may not align with customer navigation. Variant logic requires consistency. Attribute gaps become visible when customers can’t filter products.

Then there are differences between ERP and PIM definitions. Product structures diverge. Pricing sits in multiple places. Hierarchies conflict.

Your ERP might group products by supplier for procurement. Your PIM groups them by application for customer navigation. Both are correct. Integration requires deciding which structure governs commerce and maintaining that mapping as products change.

Each system functions independently. Combined, they require coordinated ownership.

If no one holds responsibility for the end-to-end data model, alignment occurs during delivery under time pressure. Quick decisions compound into technical debt.

Early shared definition and clear data ownership create stability.

Where budgets go wrong

Budget problems start with a reasonable assumption: if there’s a connector, integration can’t be that hard.

Early estimates are built on standard models. Your reseller quotes are based on typical projects. Your team references similar builds. The integration line looks stable because nobody has questioned what “typical” means for your business.

Discovery gets compressed. Data audits get pushed into the build. Business logic gets assumed. On paper, everything tracks.

Then development starts.

Field mappings multiply as edge cases surface. Your pricing model has six conditional layers that the vendor didn’t account for. Your warehouse allocation needs manual intervention, as the API doesn’t support it. Each adjustment feels minor, but they stretch timelines and burn contingency.

Connector certification doesn’t cover version compatibility, performance testing under load, or error handling design. These get attention late, when fixing them is expensive.

Then there’s organisational cost. Order processing shifts from manual steps to system-driven workflows. Approval logic that lived in someone’s head needs codifying. Data ownership becomes explicit and governed. Without planning for behavioural change, delivery teams absorb the friction.

Financial variance accumulates through small extensions and gradual scope additions.

Budget accuracy improves when investigation precedes commitment. Data review, cross-system workshops, and documented rules before final estimates get locked in—that increases predictability.

What good looks like

Integration benefits from deliberate design during planning, before development begins.

Clarity around system roles comes first. Define where pricing logic resides. Identify customer master ownership. Confirm which platform governs stock exposure.

Joint ERP, PIM and commerce workshops surface operational scenarios early. Contract ordering, partial fulfilment, variant handling and approval thresholds can be walked through before build commitments lock in.

How we integrate Magento with Orderwise demonstrates this approach in practice.

Written documentation reduces rework. Field mappings, exception-handling paths, and rule definitions create shared reference points. Without documentation, knowledge lives in Slack threads and meeting notes.

Named technical leadership maintains coherence. Without oversight, each team solves their immediate problem without considering system-wide impact.

Discovery requires a budget. Data review, edge-case testing and load simulation surface problems when they’re cheap to fix.

Integration aligned to operational reality behaves predictably under pressure.

We scope and deliver B2B eCommerce integrations that account for operational reality from day one.

The commercial impact of getting it wrong

Under-scoped integration affects revenue timing and operational stability.

Launch timelines extend. Revenue forecasts adjust. Sales teams hesitate while confidence stabilises, so the old process lingers.

Operational teams absorb strain. Pricing discrepancies trigger manual reconciliation. Stock inconsistencies generate service friction. Approval errors prompt workarounds that undermine automation.

Confidence in the platform declines gradually. Small issues accumulate. Trust erodes.

Strategic credibility weakens internally. Future digital initiatives face greater scrutiny when early programmes appear unstable or over-budget.

Technical debt accumulates when quick fixes compensate for unresolved ownership questions. Channel expansion slows. Marketplace integration requires remediation. Automation stalls when data consistency is never established.

Early integration discipline protects long-term flexibility.

The strategic view: Integration as infrastructure

Integration influences what becomes possible as your business evolves.

It determines how easily new channels are introduced, how confidently pricing automation is implemented, and how reliably live operational data is exposed to customers.

B2B eCommerce businesses evolve continuously. Product portfolios expand. Pricing models shift. Acquisitions introduce new systems. Warehouse structures change. Integration built on assumptions compounds complexity as change accelerates.

Deliberate integration design creates resilience. Clear data ownership, defined system boundaries, and documented business rules establish stability that absorbs future change.

Platform selection and vendor choice contribute to success. System alignment determines long-term sustainability.

Integration is where business architecture becomes technical architecture.

Scope it properly. Protect the programme.

Integration problems stem from planning optimism that didn’t account for operational reality.

The planning stage offers leverage. Once development begins, correction becomes slower and more expensive.

Treat integration as a primary workstream with its own budget, leadership and delivery plan. Fund structured discovery that uncovers edge cases before they become change requests. Align ERP, PIM and commerce stakeholders early. Define data ownership clearly. Document business rules thoroughly. Assign accountable technical leadership who can maintain coherence.

You’re formalising how your business operates digitally. Surfacing operational reality early creates stability under load and prevents erosion of confidence when platforms don’t behave as expected.

Integration determines whether the rest of the programme holds.