Don’t underestimate integration. Everyone does.

Integration is where good projects go wrong

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

At the platform selection stage, everything looks reassuring: there’s a connector, there’s an API, and the demo shows orders flowing cleanly from basket to backend. It feels manageable, and that early reassurance is exactly where integration gets underestimated.

---

Key takeaways

• A connector proves two systems can exchange data. It doesn’t prove your business logic, pricing rules, or approval flows will translate.
• Integration surfaces the workarounds a business has been carrying: spreadsheets, manual adjustments, agreements sitting in inbox threads, and forces decisions about how they get structured.
• According to Panorama Consulting’s ERP research, 65% of ERP implementations run over their original budget, with the average overrun reaching 53%, and integration effort is one of the biggest drivers of that gap.
• Under-scoped integration surfaces late, during build, when correction is slowest and most expensive.
• Deliberate design before development, clear data ownership, and named technical leadership are what keep integration predictable.

---

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 an undocumented regional sales agreement. 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 filling data gaps, manual adjustments, customer agreements sitting in inbox threads. Once systems connect, you need to structure those grey areas.

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.

Skip that scoping now, and it reappears later as extended timelines, unexpected change requests, and reconciliation issues that erode confidence. By the time the 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, all while balancing commercial pressure against technical constraint. The board wants progress, sales want capability, operations want stability, and finance wants predictability, often at the same time.

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 looks like a timeline dependency rather than a discipline requiring design, because an API or certified module suggests the difficult thinking is already done.

Delivery reveals the gaps: your ERP behaves differently from the demo, your PIM structure doesn’t reflect buying behaviour, and pricing logic built up over years needs translating into explicit rules. What felt manageable expands under build conditions.

Don’t underestimate integration. Everyone does.

Discovery during build is expensive because change happens once teams are already committed. Developers revise partially-built integrations, data teams re-map fields, and business teams rewrite test scenarios. The same rule that takes a day to document in planning can take 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 a documented integration path. That doesn’t account for operational alignment.

A connector doesn’t guarantee the presence of structured data, reconcile pricing logic split across systems, or resolve the gap between your internal categorisation and how customers buy. The effort sits in that gap.

When budgeting anchors to connector availability, integration feels predictable, because vendors design for common patterns. Your business carries specific decisions shaped by history and customers: workarounds that exist for good reason, approval flows that reflect internal politics rather than a textbook process.

Scope the budget around what the connector promises, rather than what your business actually needs, and the 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 shapes core operations.

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

Data ownership means defining which system is authoritative. When a customer’s credit limit appears in both ERP and commerce, one must be the source of truth, with a clear rule for who can change it and how the other system learns of the update. Without that clarity, you end up with two customer records that quietly drift apart. These are operational decisions with commercial consequences.

When you include PIM, structural choices become visible: product hierarchies, variant handling, and data quality all directly shape the buying experience.

Integration requires decisions about where rules live and who governs them, and 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. Skip that structure, and 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 living only as institutional knowledge. Connecting commerce requires making that logic explicit: customer pricing has to calculate reliably online, credit thresholds need defined approval paths, stock needs consistent representation, and allocation and backorder behaviour must be predictable. Address these dependencies during planning and design, not after.

PIM introduces its own structural dependency. Internal categorisation may not align with customer navigation, variant logic requires consistency, and attribute gaps become visible the moment customers can’t filter products properly.

Then there are the differences between how ERP and PIM define the same product. Structures diverge, pricing sits in multiple places, and hierarchies conflict. Your ERP might group products by supplier for procurement, while your PIM groups them by application for customer navigation, and both are correct within their own system. Integration means deciding which structure governs commerce, and maintaining that mapping as products change.

Each system functions independently. Combined, they need coordinated ownership. Leave the end-to-end data model without a single owner, and alignment happens during delivery under time pressure, where quick decisions compound into technical debt. Early shared definition and clear data ownership head that off.

Where budgets go wrong

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

Panorama Consulting’s 2026 ERP Report, drawing on implementations tracked through January 2026, found that more than a quarter of organisations went over their original budget, with additional technology needs and integration among them cited as the leading cause. The core software is rarely underestimated. It’s the logic and connections sitting behind it.

Early estimates are built on standard models. Your reseller quotes are based on typical projects, and your team references similar builds, so the integration line looks stable, mostly because nobody has questioned what “typical” means for your business. Discovery gets compressed, data audits get pushed into the build, and business logic gets assumed. On paper, everything tracks.

Then development starts, and field mappings multiply as edge cases surface. Your pricing model turns out to have six conditional layers the vendor didn’t account for, and your warehouse allocation needs manual intervention because the API doesn’t support it. Each adjustment feels minor on its own, but together they stretch timelines and burn contingency.

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

Then there’s the organisational cost. Order processing shifts from manual steps to system-driven workflows, approval logic that lived in someone’s head needs codifying, and data ownership becomes explicit and governed. Without planning for that behavioural change, delivery teams absorb the friction, and financial variance accumulates through small extensions and gradual scope creep.

Budget accuracy improves when investigation precedes commitment. Data review, cross-system workshops, and documented rules before final estimates get locked in all raise 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, and confirm which platform governs stock exposure.

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

(For a worked example, see how we integrate Magento with Orderwise.)

Written documentation reduces rework. Field mappings, exception-handling paths, and rule definitions create shared reference points that survive staff changes and long projects. Without documentation, that knowledge lives only in Slack threads and meeting notes.

Named technical leadership maintains coherence. Without oversight, each team solves its own immediate problem without weighing the system-wide impact.

Discovery needs a budget of its own. Data review, edge-case testing and load simulation surface problems while they’re still cheap to fix, and integration designed this way behaves predictably under pressure.

(If you’re scoping this now, see how we approach B2B eCommerce integration.)

The commercial impact of getting it wrong

Under-scoped integration affects revenue timing and operational stability.

Launch timelines extend, and revenue forecasts adjust. Sales teams hesitate while confidence stabilises, so the old manual process lingers longer than anyone planned.

Operational teams absorb the strain. Pricing discrepancies trigger manual reconciliation, stock inconsistencies generate service friction, and approval errors prompt workarounds that undermine the automation you paid for. Confidence in the platform declines gradually as small issues accumulate, and trust erodes with it.

Strategic credibility takes a hit too. Future digital initiatives face greater scrutiny once early programmes appear unstable or over-budget, and technical debt builds as quick fixes compensate for ownership questions nobody resolved. Channel expansion slows, marketplace integration needs remediation, and automation stalls because data consistency was never properly established.

Early integration discipline protects long-term flexibility.

The strategic view: Integration as infrastructure

Integration shapes what becomes possible as your business evolves. It determines how easily you introduce new channels, how confidently you implement pricing automation, and how reliably you expose live data to customers.

B2B eCommerce businesses evolve continuously: product portfolios expand, pricing models shift, acquisitions introduce new systems, and warehouse structures change. Integration built on assumptions compounds that complexity as change accelerates.

Deliberate integration design creates resilience instead. Clear data ownership, defined system boundaries, and documented business rules establish a foundation that absorbs future change. Platform selection and vendor choice matter, but system alignment is what 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 how the business actually operates.

The planning stage offers the greatest 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, and document business rules thoroughly. Assign accountable technical leadership who can hold all of it together.

You’re formalising how your business operates digitally. Surfacing the reality of that early creates stability under load, and stops confidence eroding when platforms don’t behave as expected.

Integration determines whether the rest of the programme holds.