What a replacement project really costs you
Implementing a new core system is rarely a technical project. It's an organisational project that happens to involve software too. Migrating historical data, reshaping processes, the resistance from people who've worked the same way for ten years: that's where the time and the money go. Then comes the learning curve on top. Not because suppliers do it badly, but because replacing a core system always touches more than the system supplier can see coming. That's no reason never to replace. It is a reason to put the question sharply: what are you actually trying to solve?
When replacement is the right choice
If the fundamental data model is wrong, an AI layer won't get you any further. If your ERP has no single source of truth for orders, items or customers, then automation on top of that system is built on a leaking foundation. The same holds when your business process changes fundamentally, say through an acquisition, a new market or an entirely different product model. Sometimes an existing system simply doesn't have the architecture to carry that. In those cases replacement is the most honest choice. An AI layer would only treat the symptoms.
When an AI layer is faster and cheaper
In most situations we come across, the core system is actually sound. The problem is at the edges: documents retyped by hand, quotes that pass through three people before they go out, data pulled out of the system into Excel to base a decision on. Those aren't system problems. They're process breaks. And you fix them by closing the breaks, not by replacing the system behind them. An AI layer that connects to your existing ERP, TMS or WMS can close those breaks without you migrating, retraining and waiting eighteen months for go-live. People carry on working in the system they know. The AI does the typing and the groundwork.
The honest trade-offs
An AI layer is no magic fix. If your existing system really is outdated, you're building up further technical debt. You still have two systems to maintain instead of one new one. And the integrations you build need attention when the core system gets an update. Those are real costs. On the other hand: a replacement project takes a long time, asks a lot of your organisation and only pays off well down the line. The question isn't which option is painless. Neither one is. The question is which pain fits your situation, and which one your organisation can carry right now.
How to make the call without ending up in a sales pitch
Start from the problem on the shop floor, not the technology. Ask: what is someone doing by hand right now that should really run automatically? Is it something the existing system could in principle already do, but doesn't because the input is messy or the integration is missing? Then an AI layer is the most honest starting point. Is it something the system will never be able to do architecturally, because the data model won't allow it? Then replacement is more honest. Put both options side by side with the same honesty: what does it cost in money, in time and in organisational capacity? And who ends up owning the result? With a replacement project you depend on the supplier of the new system. With a well-built AI layer you own the code, the data and the logic. That's a real difference in who's in control.