ERP integration that leaves the core alone.

Integrate around it, in nearly every case. Core customisation is the single most common reason businesses end up stranded on an unsupported ERP release, because each modification has to be reworked at every upgrade. Building the missing capability as a separate application that talks to the ERP through supported interfaces gives you the same functionality and keeps the upgrade path open.

Usually yes. Older systems often lack a modern API, so we use what they do offer — web services, supported staging tables, import and export routines driven automatically, or a read replica for reporting. We avoid unsanctioned writes to ERP tables, because that is how data integrity and vendor support are both lost.

Because the website is usually working from a copy that updates on a schedule, and because “available” is a calculation rather than a number — it has to account for allocated stock, goods in transit, minimum levels and multiple locations. We derive one availability figure in the ERP, publish it to every channel, and reconcile continuously so the discrepancy is visible if it ever returns.

No. We are not a reseller and we do not run ERP selection or implementation programmes. We integrate and extend the ERP you already have, which means we have no commercial reason to recommend replacing it — and we will tell you when the honest answer is that the ERP is fine and the problem is elsewhere.

By replicating the data you need into a separate reporting store on a schedule the operation can absorb, then running all analysis against that. This stops month-end reporting competing with despatch for the same database, and it lets you keep history that the ERP would otherwise archive away.

A single high-volume flow — web orders into the ERP, or stock out to the channels — is typically a low five-figure project. Larger programmes covering warehouse, carriers, CRM and reporting are phased, and the interface survey that comes first is a small fixed-price piece of work that is useful regardless of what you build next.

It should not, and that is the point of working only through supported interfaces. Unsanctioned writes to ERP tables are what void support and corrupt data, which is why we do not do them. Where an ERP offers no sanctioned route we build a controlled staging layer and document it, so your vendor can see exactly what touches what.

Yes, and protecting that is the main reason to extend around rather than customise within. Because the extensions are separate applications talking through supported interfaces, a vendor upgrade becomes a planned project with a test cycle rather than a rewrite of bespoke code. Losing the upgrade path is how businesses end up stranded on an unsupported release.

It depends on the decision it supports, and over-specifying it is expensive. Stock published to a website usually needs to be near real time; reporting data usually does not. We agree the latency per flow in the interface survey rather than defaulting everything to instant, because constant polling of an ERP has a real cost.

Regularly. The first phase is the interface survey precisely because every ERP is different and the documentation is often optimistic. We establish empirically what the system will actually let us do before anything is designed around it, which is also when we find out whether the vendor’s API does what the brochure says.