Custom Software · 7 min read
Connecting Your ERP Without Launching a Mega-Project
Few phrases trigger as much resistance in management as “ERP project”. Almost everyone knows a story: the rollout that took twice as long as planned, the consultant day rates, the module nobody ended up using. That resistance is justified, but it often hits the wrong target. Connecting an ERP is fundamentally different from introducing or replacing one. The ERP stays exactly as it is. It just finally gets company that talks to it.
Connecting means: the ERP stays untouched
In an integration, nothing inside the ERP gets rebuilt. A piece of software is created next to it that writes data in or reads data out, through the channels the system provides for that purpose. Accounting keeps working as before, nobody needs retraining, no data migration, no parallel operation of two worlds.
That is also why an integration is feasible in weeks where a rollout takes months: the risky part of an ERP project is never the technology, it is changing how twenty people work. That part simply does not apply here.
The adoption numbers show how high the barrier of a classic rollout is. According to Eurostat (2025), 89% of large enterprises in the EU use ERP software, but only 41% of small ones. That gap is rarely about missing need. It is about the effort a rollout takes.
Source: Eurostat, ICT usage in enterprises, 2025
The smallest useful cut: one direction, one document type
The classic mistake is packing every wish into one project: orders in, stock levels out, customer data in sync, reporting on top. Each of these connections is manageable on its own; together they are a mega-project, and you are back in the story from the beginning.
What holds up better is the smallest cut that is noticeable in daily work: one data direction, one document type. An example: a wholesaler with a webshop has been transferring orders into the ERP by hand, a good hour every day. The first stage automates exactly that, nothing else. Stock levels back into the shop, customer sync, shipping status, all of that comes later, as separate small stages on a foundation that has proven itself. Once the first stage runs, each following one is cheaper, because the connection, logging, and error handling already exist.
When the ERP has no API
Many long-serving ERP systems in mid-sized companies have no modern API. That is an obstacle, not a dealbreaker, because almost every system offers some way in or out: file import and export, an email inbox, in some cases direct database access. Over bridges like these, even software from the nineties can be connected.
The honest part of this: a bridge is more maintenance-heavy than a real API. If an update changes the export format, the bridge has to follow. That is why every bridge solution needs monitoring that reports when data stops flowing, and a plan for what happens then. Anyone selling you a bridge without those two things is selling you a ticking clock.
Clarify with your ERP vendor first
Before anyone writes code, three questions belong with the vendor or support partner of your ERP. First: which official channels for data exchange exist, and what do they cost? Some vendors charge separate license fees to unlock their API, and those belong in the calculation. Second: does the maintenance contract remain unaffected if a third party accesses the system through the official channels? Third: how does the vendor announce changes that affect the interfaces?
This clarification costs one phone call and a few emails and prevents the two most common nasty surprises: hidden license fees, and a support partner who, at the next incident, takes the position that the third-party system is to blame. Best practice is to communicate the integration openly to the vendor, not build it behind their back.
Realistic timeline and cost
A first stage like the order transfer in the example typically takes three to six weeks and costs €5,000 to €12,000 with an ERP that has a usable API. With a bridge solution, expect the upper end, plus higher ongoing maintenance. These are not inflated numbers: anyone offering you an ERP integration for €1,500 has not priced in error handling and logging, and those are exactly what separates an integration from a hobby project.
The same sobriety applies upward: if a quote for a single data direction reaches six figures, someone is probably selling you a mega-project after all. Then the useful question is what the smallest cut would be, and what only that costs.
How to tell the integration is well built
You do not recognize a good integration by the fact that it works when everything goes smoothly, but by what happens when it does not. If the ERP is unreachable for a night, the data waits and gets delivered afterwards instead of getting lost. If an order arrives with data the ERP will not accept, it lands on a review list with a notification instead of vanishing silently. And there is a log where an employee without technical training can check whether order 4021 was transferred.
These points belong in the quote, not in the renegotiation. If they are missing, the lower price is only borrowed.