Skip to main content
Talk to an expert
RescueERP integration

ERP integration rescue.

ERP is the system of record for price, stock, accounts and orders. When the boundary with ecommerce drifts, finance numbers stop tying out and customer experience breaks quietly. We work across the common UK ERP stacks (Sage 200, Sage X3, Microsoft Dynamics 365 Business Central, NetSuite, Intact iQ, Epicor BisTrack, Kerridge K8, SAP Business One) and treat the boundary as the design.
600+
Commerce projects
40+
Engineers · on staff
31
Years · systems behind commerce
1995
Founded
01 · What we look at first

What we look at first

ERP boundary as the design
Price, stock, accounts and orders live in ERP. The storefront reads through a governed boundary; the boundary itself is the most important integration decision.
Pricing read paths
Customer-specific pricing, contract pricing and trade discounts read from ERP without exposing the ERP to web traffic.
Stock and availability
Multi-depot stock, reservations and back-order behaviour modelled honestly rather than hidden behind a single number.
Order handoff and acknowledgement
Order creation, acknowledgement, edits and cancellations governed across the boundary with reconciliation reports.
Account and credit
Trade accounts, credit limits, hold status and statements reflected on the storefront with the right level of detail.
Reconciliation reporting
Storefront and ERP reports that agree by source, not by accident. Finance numbers tie out by design.
Read cadence and caching
Read paths cached at the storefront boundary; writes posted through monitored queues. ERP load protected by design.
Sage and Dynamics estates
Sage 200, Sage X3, Microsoft Dynamics 365 Business Central, NetSuite, Intact iQ, Epicor BisTrack, Kerridge K8 and SAP Business One are common UK examples; we treat the integration shape, not the badge.
Middleware honesty
Where middleware is helping, we keep it. Where it is hiding the boundary, we name that and clean it.
Observability across the boundary
Throughput, failures, retries and reconciliation reports surfaced as visible signals with on-call ownership.
Versioned, governed contract
The integration contract written down, versioned and reviewable rather than implied behaviour.
Honest "rebuild" call where needed
Where the existing integration genuinely cannot be stabilised, we say so and outline the staged rebuild.
03 · Platform fit and estate context

How this platform fits the wider commerce estate.

Fit against operational shape
Catalogue depth, trade complexity, branch logic and ERP integration named honestly before the platform decision is fixed, not assumed from a vendor demo.
Integration boundary with ERP
ERP owns commercial data, pricing and stock. The commerce platform reads the boundary through governed APIs; the boundary itself is the most important design decision in the estate.
PIM as the catalogue system of record
Deep catalogue governance lives in PIM (Akeneo, Salsify or similar). The commerce platform reads from PIM rather than re-modelling product data in the storefront.
OMS and fulfilment surface
Order management, partial dispatch, returns and customer-visible order state live in operational systems. The platform reads what operations actually did.
Search and merchandising
Native search plus specialist engines (Algolia, Constructor.io) assessed against the actual query mix, not a vendor benchmark. Relevance is a continuous activity.
B2B and trade behaviour
Account-only catalogues, customer-specific pricing, depot stock, quote-to-cart and partial dispatch modelled inside the platform rather than patched at the storefront.
Multi-store and multi-territory
Brand, market and territory storefronts modelled with shared catalogue, pricing and operations rather than parallel sites that drift apart.
Total cost over five years
Licence, hosting, engineering and support modelled honestly across the lifecycle, not just year one. The cheap year-one platform is often the expensive five-year one.
Headless and composable trade-offs
Headless or composable storefronts where they earn their place, not as a default. The trade-off between optionality and integration surface is named upfront.
Operational ownership and runbook
Long-term support, releases and integration ownership inside a UK agency that runs platforms day to day, with a written runbook the on-call team can act on.
Replatform sequencing
Where a platform move is on the table, sequencing by domain, traffic share or territory keeps trading live throughout. Big-bang relaunches are rarely the right shape.
Honest "do not move" advice
Where the existing platform is the right answer, iWeb says so on the record. A senior, written read on the brief is the deliverable, not a sales pitch.
04 · Questions we get asked

Questions we get asked.

Do you only do Sage 200?

No. Sage 200 is one of several ERPs iWeb integrates with; Sage X3, Microsoft Dynamics 365 Business Central, NetSuite, Intact iQ, Epicor BisTrack, Kerridge K8 and SAP Business One all appear in our work. The pattern matters more than the badge.

Will you replace our middleware?

Only where it earns its place. Many rescues end with the same middleware kept and stabilised; some end with a thinner boundary. The decision is written down with trade-offs.

How does an iWeb rescue actually start?

With a short, written read on the brief. We look at what is broken, what is still working, where trading risk sits and what we would protect first. No drama, no pitch.

Do you blame the previous team?

No. Blame slows recovery down. We describe what we see, sequence what matters, and write down trade-offs so the owner can make informed calls.

Will you push us to replatform?

Only when the current platform genuinely cannot carry the next twelve months. Most rescue work is stabilisation first; rebuild is the second conversation, not the first.

How does iWeb choose between platforms?

Against operational shape: catalogue depth, trade complexity, ERP integration, multi-territory rules and five-year cost. The decision is written down with trade-offs, not assumed from a vendor demo.

Where does ERP integration sit in the platform decision?

It is a primary input. Some platforms make ERP integration straightforward, some make it expensive. iWeb names the trade-off rather than hiding it.

Does iWeb deliver headless or composable storefronts?

Where they earn their place. The trade-off between optionality and integration surface is named upfront; composable is not a default.

How is search handled on this platform?

Native search where the query mix supports it; specialist engines (Algolia, Constructor.io) where the catalogue, volume or merchandising appetite justify them. Relevance is a continuous activity.

Where does PIM sit relative to the commerce platform?

PIM owns catalogue truth (attributes, variants, assets, channel readiness). The commerce platform reads from PIM rather than re-modelling deep product data in the storefront.

Can iWeb take over an existing build on this platform?

Yes, where the brief fits. iWeb will give a senior, written read on what is working, what needs remediation and what is honestly fixable, and the first month on support stays deliberately conservative on change.

How does iWeb size a five-year total cost picture?

Licence, hosting, engineering and support across the lifecycle, including the integration surface and operational ownership. The headline year-one number is rarely the honest comparison.

Accreditations & assurance
Gold Commerce Partner
Specialised in Commerce & AI
ISO certified
27001 · 9001 · 42001
Cyber Essentials Plus
Independently verified security
WCAG 2.2 AA
Accessibility embedded by design
Employee-owned
The same team, long term
Next step

Talk about a rescue, in confidence

Send the brief. You'll get a written response from a senior expert on the platform, ERP and operational realities we'd look at first, not a pitch deck.
Talk to an expertor see the rescue suite →