Should I build an AI layer around my existing ERP or rebuild the system?
That is exactly the right question, but the answer does not start with technology. It starts with honesty about your current system. An AI layer on top of existing ERP makes sense if the system is less than ten years old, has reasonable API integrations, and your data is in order. Rebuilding makes sense if the system is older, no longer aligns with how your business operates, and you already see replacement costs coming in the medium term. Most companies move too quickly toward the AI layer because it feels like the safer, cheaper route. It often is not.
Five criteria that determine the choice
Use these five points as a checklist. ERP age: systems older than ten to fifteen years are often built on architectures that make AI integration expensive. The connection may work, but it remains a patchwork. Data quality: if your master data is polluted (duplicate customers, inconsistent item codes, incomplete historical orders), AI amplifies that problem rather than solving it. API integrability: does the system have stable, documented APIs? If not, the AI layer depends on fragile screen scrapers or exports. Total cost of ownership: add up licensing costs, maintenance, integration work, and expected lifespan. Rebuilding is sometimes cheaper over five years than continuing to patch. Strategic horizon: will your business model change over the next five years? If so, you want a system that can handle that, not one you chose in 2019 and have not touched since.
The most common mistake: building AI on bad data
This point deserves its own heading, because it kills the investment more often than the wrong route choice does. AI operates on data. If your ERP has been maintained manually for years, if order lines contain incomplete product codes, if customer addresses exist in four variations, then an AI layer produces inconsistent output. The system guesses rather than supports. That is not an AI problem, it is a data problem. The question of whether to build a layer or rebuild only becomes meaningful once that foundation is in order. Rebuilding sometimes gives you a clean slate: you decide which data to carry over and how to clean it. With an AI layer on an existing system, you carry that pollution with you.
Who executes this in the Netherlands?
The market in the Netherlands can broadly be divided into three types of parties. Large system integrators such as Capgemini, Atos, and Cognizant carry out AI integrations on existing enterprise systems. They work on a project basis, have broad expertise, and are best suited to large organisations with an existing enterprise system that is well documented. ERP-native AI specialists are parties that build AI modules specifically for a particular ERP platform; their knowledge runs deep within the package but rarely extends beyond it. Independent software development partners, such as Bonsai Software, rebuild core systems entirely from scratch or add an AI layer (via Workers) to existing systems, domain-specific and with code and data ownership held by the client. A fourth category you should not overlook: independent advisors and IT architects who do not write code but help you make the decision and draw up a specification before you approach a builder. That combination, advisor plus builder, is often the most sensible approach in complex situations.
When does Bonsai fit, and when does it not?
Bonsai Software rebuilds domain-specific core systems entirely from scratch, with AI built in, for sectors including logistics, port, food, customs, trade, and industry. We do this when an organisation is ready to replace its core system and take ownership of the code. We also build AI Workers on existing systems for organisations that want to keep that core system for the time being but reduce operational burden. We are not the right fit if you are looking for a standard ERP rollout with configuration adjustments, if you need fully independent architectural advice without implementation, or if your budget and timeline are too tight for serious software development. We say this explicitly, because a poor match helps no one.