Why EDI integration is tied to your old ERP
EDI (Electronic Data Interchange) connections look like they belong to the partner. In practice they belong to whichever system sits behind them.
A customer sending you a purchase order is sending it in an agreed format, with agreed identifiers, to an agreed endpoint. Those identifiers come from your ERP. The article numbers, the customer codes, the unit of measure conventions, and the tax codes are all your system's vocabulary, translated once when the connection was built and frozen in place ever since.
Four things usually sit in that translation:
- Product identifiers: your article numbers mapped to the partner's own catalogue references, item by item
- Partner and location codes: which customer, which delivery address, which branch, expressed in codes your ERP issued
- Document structure: which fields are mandatory in an order, a despatch advice, or an invoice, and in what sequence
- Validation rules: what the partner rejects, including tolerances on quantity, price, and delivery window
None of that is documented in one place at most businesses. It sits in the connection itself, and in the memory of whoever built it. That becomes a problem the moment the system underneath changes.
What breaks when the ERP underneath changes
A new ERP issues its own identifiers. Article numbers change, customer codes change, and the data model that produced the original mapping no longer exists.
The failure is rarely dramatic. An order arrives and is rejected because a field the partner expects is now empty. An invoice is accepted and then disputed because the tax code maps to something different. A despatch advice goes out with a unit of measure the partner reads as cases rather than pallets.
These surface one partner at a time, which is what makes them expensive. A business with dozens of EDI partners does not get one failure. It gets a queue of them, each needing a different person at a different company to confirm a fix.
The same pattern applies to data migration more broadly, which is covered in migrating ERP and WMS data with an integration platform. EDI is the version where somebody outside your business has to agree before anything is fixed.
What reworking EDI integration actually costs
The remapping is not the expensive part. An analyst can rebuild a mapping in hours. What it costs the business sits around that work:
- Orders rejected at the partner's end: a missing field means the order never reaches your system, and the customer chases you rather than their own EDI team
- Invoices disputed rather than paid: a tax code that maps differently becomes a credit note, a conversation with finance, and cash that arrives a month late
- Your largest customers asked for a favour: EDI changes need partner-side testing, so a system replacement turns into a request to the companies you are trying to sell to
- The same work again next time: mappings rebuilt against the new ERP are tied just as tightly to it, so the following replacement costs the same
- Replacement delayed or avoided: businesses with large EDI estates often postpone system changes because of what the rework will cost them
The last one is the real price. EDI stops being a technical obligation and becomes a reason not to change systems at all.
How an integration platform handles EDI integration
An iPaaS (integration Platform as a Service) gives a business one place where all its systems connect. Every system connects to it once instead of connecting directly to each other, and the platform moves and reshapes the data between them. Businesses use it for everyday work: orders from the webshop into the ERP, stock back out, despatch data to a carrier.
EDI runs on the same arrangement, with one difference that matters here. The partner connects to the platform rather than to the ERP. The mapping between the partner's format and your data model lives in the platform, not inside the connection, so changing what sits behind it does not change what the partner sees.
The Alumio integration platform provides features that can be configured to keep EDI connections stable through an ERP change:
- The partner endpoint stays put: partners keep sending to the same place in the same format, so a replacement behind the platform needs no partner-side change
- Mappings are visible and editable: a Transformer holds the translation between partner formats and your identifiers, so remapping to a new ERP is a configuration change your own team can make
- Both systems can run at once: flows can point at the old ERP and the new one during cutover, so nobody depends on a single switchover date
- You can see what each partner sent: message logs show exactly what arrived and what was returned, which is what settles a dispute with a partner rather than prolonging it
Alumio also provides an EDI Broker for businesses that want the connection managed rather than built. The same principle applies outside EDI. AGU connects its Centric ERP to Adobe Commerce and Akeneo through Alumio rather than directly, with its data normalised so other tools can be connected later. New channels can then be added as additional Routes instead of rebuilding what already runs.
What partner-independent EDI integration gives you
EDI is usually treated as a legacy obligation, maintained because large customers require it. That framing is why it ends up last in the plan and first in the delay.
The ERP is not the problem either. A business should be able to replace it when the old one stops fitting, and most of that project is work it controls. What makes the decision harder than it should be is that the ERP ends up holding translations for systems far beyond itself: the trading partners, but also the webshop, the warehouse, and the carriers. Moving those translations into an integration layer separates the two, so partners keep their endpoint and the ERP goes back to being an ERP.
What the business gets is a system landscape it can change on its own timeline, where replacing the ERP is a project rather than a negotiation, and where EDI integration outlives whichever system it was originally built for.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
