The ERP market is going through a quiet repricing. Customers no longer evaluate a system by whether it records transactions correctly — that is assumed. They evaluate it by whether it can turn their daily data into insight, recommendations, and forecasts. A system that only stores and reports is being reclassified, in buyers' minds, from "platform" to "database with screens."
This lands hardest on legacy and locally-built ERPs. Many of them are genuinely good products: deep functional coverage, loyal customers, years of accumulated business logic. But they were designed in an era when a weekly report was a deliverable, not a disappointment. Their owners now face a question that feels existential: rewrite, or fade?
This post argues for a third answer — one we have designed for a regional ERP vendor and generalised here: keep the system, add the intelligence.
The squeeze on legacy ERP
Three pressures are converging on every established ERP at once:
What a legacy ERP delivers today
- Reports arrive weekly, by email, already out of date
- Analysts spend most of their time preparing and cleaning data, not analysing it
- Every non-standard question becomes an IT ticket
- Answers require learning the system's screens and menus
What buyers now expect
- Real-time insight on their own screens
- Questions asked in plain language — and answered in it
- Dashboards that reflect this moment, not last week
- AI features as a baseline, because the global platforms bundle them by default
The third pressure is the decisive one: the large international platforms are embedding AI layers as standard features. Every one of their sales demos resets what your customers think an ERP is supposed to do. The gap doesn't need to be real to hurt you — it only needs to be visible in a procurement meeting.
Three layers, not one rewrite
The pattern is a set of three independent layers that sit on top of the existing ERP — connecting through its APIs where they exist, or a secure read path to its database where they don't — and inheriting its permission model, so users can only ever see what their role allows.
Layer 1 — Talk to the system
A sales manager, a finance director, or a CEO asks: "How did the northern branch sell last week against the same period last month — and what were the top three product categories?" — and gets a structured answer immediately: figures, comparison, context. No new screens to learn, no ticket to IT. Technically, this is a custom MCP (Model Context Protocol) server built for the ERP's architecture, with guardrails against prompt abuse, a full audit log of every question and answer, and flexible model choice — hosted frontier models, or open-source models running entirely inside the customer's environment for high-confidentiality deployments.
For a regional vendor there is a differentiator hiding here: Arabic that actually works — not a translated interface, but genuine understanding of the dialects and business shorthand your users really type. The global platforms are weakest exactly where your customers live.
Layer 2 — See the business live
Role-based dashboards on real-time data: sales, margins, inventory, liquidity, customer satisfaction. Behind them sits a modular pipeline — extraction (scheduled or change-data-capture), a lakehouse in three zones (raw, clean, ready), and a central semantic model where business logic is defined once so every report agrees with every other report. It runs on whichever cloud matches the customer's existing investment.
Layer 3 — Get ahead of events
Machine-learning models that move the conversation from "what happened?" to "what will happen, and what should we do?" — which customers are likely to churn, which stock lines will run out, which anomalies deserve attention. Deliberately last in the sequence: it needs the historical data quality the first two layers create, and a customer who has developed the habit of acting on evidence.
Why a layer beats a rewrite
Every vendor who feels this pressure considers the rebuild. The comparison deserves to be made honestly:
| Rewriting the product | Adding an intelligence layer | |
|---|---|---|
| Time to visible value | Years before customers see anything new | A working conversational interface within the first phase |
| Risk | Betting the company on a parallel build while the market moves | Staged delivery — assessment, prototype, build, deploy — with value proven at each step |
| Existing investment | Written off, together with years of embedded business logic | Becomes the foundation the new layers are built on |
| Sales story | "A new version is coming" — which freezes current sales | A tiered upgrade path that raises contract value per customer today |
| Revenue model | Same licence, higher cost base | Recurring revenue from analytics and value-added services |
The strategic window
The global platforms have the AI, but not the regional depth — the language, the dialects, the local business practices, the relationships. That advantage is real but temporary. The vendors who move while "ERP + AI + Analytics" is still a differentiator in their market will set the standard the others are compared against.Sequencing it honestly
-
Start with conversation
The conversational layer is the fast, visible win — it demos beautifully, deploys without touching the ERP's internals, and changes how users feel about the product within weeks.
-
Prepare analytics in parallel
The dashboard layer takes longer because it involves real data engineering. Starting its groundwork alongside Layer 1 means the second release lands while the first is still generating goodwill.
-
Hold prediction until the data is ready
Predictive models trained on poor historical data produce confident nonsense. Put Layer 3 on the roadmap, sell it as a future tier — and build it only when the first two layers have matured the data that will feed it.
The part that makes or breaks trust
An AI layer that can see everything is a liability, not a feature. The security model has to be inherited from the ERP itself — every user sees only what their existing role permits — with guardrails against sensitive prompt execution and a complete audit trail of every question, who asked it, and what was answered. Governance is not the boring part of this architecture; it is the part that makes the rest sellable.What changes for the vendor — and the customer
For the vendor
- Clear differentiation against local competitors — and a credible answer to the global platforms
- Higher contract value per customer through a three-tier sales path
- Recurring revenue from analytics and value-added services
- Faster time to market than building AI expertise in-house from zero
For the end customer
- Faster, surer decisions from real-time access and natural-language interaction
- Lower analysis costs — routine questions stop needing a specialist
- Visibility from every branch up to headquarters
- A modern experience that matches what users now expect of every tool
Neither side has to abandon anything. The system that runs the business keeps running it — and starts answering for it too.
Own or sell a system like this?
We designed this pattern for a working ERP vendor and generalised it — the same layers apply to any operational system with data worth asking about. If your product or your organisation is sitting on one, let's talk about which layer to start with.