Legacy integration is the practice of connecting existing, often older business software to modern AI services and tools through intermediary layers, APIs, or middleware — without replacing the original system. For SMBs in the Netherlands, where companies run an average of five to eight software systems with at least two older than ten years, this is the most cost-effective path to AI adoption.
The instinct at many companies is understandable: "We need to modernize everything before we can do anything with AI." That is almost never true. Your accounting system from 2016 does not need to be replaced to run AI-driven cash flow predictions. Your CRM that has been running for eight years does not need to go to connect a chatbot. What you need is a bridge — not a wrecking ball.
What makes a system "legacy"?
Legacy software is software that still functions and is business-critical, but was built on outdated technology or architecture. That does not necessarily mean it is bad — it means it is harder to make it work with modern tools.
Characteristics of typical legacy systems in Dutch SMBs:
- On-premise installation — runs on a local server, not in the cloud
- Limited or no API — communication happens via exports (CSV, XML) or manual entry
- Past custom development — built years ago by a local IT company, minimal documentation
- Deeply embedded in business processes — everyone uses it, nobody knows exactly how it works internally
- Vendor lock-in — the vendor controls update timing and customization pricing
Examples we encounter regularly: older versions of Exact Globe, Navision (now Dynamics 365 Business Central), SAP Business One, custom-built Access databases, and industry-specific software from small vendors.
Why "rip and replace" is almost never the right choice
Full replacement sounds clean and simple. In practice, it rarely is:
| Factor | Replacement | Integration |
|---|---|---|
| Cost | EUR 50,000-500,000+ | EUR 5,000-50,000 |
| Timeline | 6-18 months | 4-12 weeks |
| Business risk | High (migration, data loss, training period) | Low (existing system keeps running) |
| User resistance | High (learning new system) | Low (existing workflow stays) |
| Data loss risk | Real (migration is complex) | Minimal (data stays where it is) |
| Flexibility | Locked in for years | Incrementally expandable |
This mirrors what we describe in our article on custom software vs. off-the-shelf solutions — the choice is rarely black and white.
When replacement IS justified:
- The vendor no longer exists and there is no support
- The system runs on hardware that is no longer available
- Security risks are unacceptable (no updates, known vulnerabilities)
- The cost of workarounds exceeds the cost of replacement
In all other cases, integration is faster, cheaper, and less risky.
What integration patterns are available?
There are four common approaches to connecting legacy systems to AI. Each has its own costs, complexity, and use cases.
Pattern 1: Direct API connection
The legacy system offers an API (REST, SOAP, or even an older variant). You build a connection between that API and the AI service.
Example: Exact Online offers a REST API. You can retrieve invoice data, run it through an AI model for cash flow prediction, and write results back.
Advantages: direct connection, no intermediary layer, relatively simple. Disadvantages: not every legacy system has a usable API.
Learn more about how API connections work in our article API integration explained.
Pattern 2: Middleware / integration layer
A middleware layer sits between the legacy system and the AI service. It translates data from one format to another, handles authentication, and catches errors.
Example: you have an old ERP system that can only do CSV exports. A middleware layer automatically retrieves those exports (via a scheduled job or file watcher), transforms the data to JSON, and sends it to an AI API.
Platforms: Make (formerly Integromat), n8n (open source, self-hostable), Azure Logic Apps, or a custom-built Node.js/Python service.
Advantages: flexible, works with virtually any system, decouples source and target. Disadvantages: additional component to maintain, potential latency.
Pattern 3: Database connection
Some legacy systems offer no API but run on an accessible database (SQL Server, MySQL, PostgreSQL). You can read directly from the database — provided you are careful.
Example: a custom-built inventory management system runs on SQL Server. You write a read-only query that daily retrieves stock levels and sends them to an AI model for demand forecasting.
Advantages: works even when there is no API, access to all data. Disadvantages: risky if you write to the database (can break the system), requires knowledge of the data model, can cause performance issues.
Golden rule: always read via a replica or read-only connection. Never write directly to the production database of a legacy system. Before connecting legacy data to AI, make sure the data itself is in good shape — our guide on making your business data AI-ready covers exactly what to check.
Pattern 4: RPA (Robotic Process Automation)
If the system has no API, no accessible database, and only a graphical interface — then RPA is the last resort. A software robot clicks, types, and reads the screen, exactly as a human would.
Example: an industry-specific Windows application from 2008 with no API. An RPA bot opens the program, navigates to the reporting screen, exports the data, and sends it to an AI service.
Advantages: works with literally any system a human can operate. Disadvantages: fragile (breaks with every interface change), slow, difficult to scale.
Our recommendation: use RPA only as a temporary bridge while you build a better integration. It is never the final solution.
How do you choose the right integration pattern?
| Situation | Recommended pattern |
|---|---|
| System has a modern REST/GraphQL API | Direct API connection |
| System has an old SOAP/XML API | Middleware with transformation |
| System has only a database | Database connection (read-only) |
| System exports CSV/Excel files | Middleware with file processing |
| System has only a GUI | RPA (as temporary bridge) |
| Multiple systems connecting to AI | Middleware as central hub |
The choice is not always technical — it is also organizational. What expertise do you have in-house? Which partner supports the legacy system? How critical is the data for the AI model? Those questions are answered in an assessment, not a meeting room.
Save 10 hours per week on manual retyping, exporting, and importing between old and new systems
Step-by-step modernization: the strangler fig pattern
The smartest approach to legacy modernization is the strangler fig pattern — named after the tropical fig tree that gradually grows around an existing tree and eventually replaces it.
How it works:
- Keep the legacy system running. Change nothing in the core.
- Build new functionality alongside it. Every new feature is built as a modern service that communicates via API.
- Gradually redirect traffic. New users and processes use the new service. Existing processes stay on the old system.
- Migrate step by step. When a function in the new system is proven, you switch off that function in the old system.
- Eventually the legacy system disappears. Not with a big bang, but gradually — without the business being affected.
This pattern is proven across companies of every size, from scale-ups to banks. For SMBs it works particularly well because you spread the investment over time instead of paying everything upfront.
This is comparable to the trade-offs we describe in our article on no-code vs. custom development: start with what delivers value fastest and build from there.
Common legacy systems in Dutch SMBs
These are the systems we encounter most frequently in integration projects:
AFAS Profit — offers an extensive REST API (GetConnectors and UpdateConnectors). Well-connectable. Challenge: the API has specific conventions you need to understand.
Exact Globe / Exact Online — Globe (on-premise) has an XML interface and limited API. Exact Online (cloud) has a modern REST API. If you are still on Globe, the switch to Online is often worthwhile purely for API access.
SAP Business One — Service Layer API (REST-like) available since version 9.3. Older versions require the DI API (COM-based), which is more complex. Well-connectable with middleware.
Microsoft Dynamics NAV / Business Central — NAV (on-premise) has OData and SOAP web services. Business Central (cloud) has a modern REST API. The migration from NAV to BC is a major project, but the API improvement is substantial.
Access databases and Excel macros — a surprising number of SMBs run business-critical processes on Access or Excel VBA. No API, but data is accessible via ODBC or direct file access. Middleware can retrieve this data and forward it to AI services.
More on software decision-making in our SMB digitalization guide.
What does legacy integration cost?
Costs depend on the integration pattern, the complexity of the legacy system, and how many data flows you want to connect.
| Integration pattern | One-time cost | Monthly cost |
|---|---|---|
| Direct API connection (simple) | EUR 2,000-8,000 | EUR 50-200 |
| Middleware integration | EUR 5,000-20,000 | EUR 100-500 |
| Database connection + transformation | EUR 3,000-12,000 | EUR 50-300 |
| RPA bridge | EUR 5,000-15,000 | EUR 200-800 |
| Strangler fig (full trajectory) | EUR 15,000-80,000 | EUR 200-1,000 |
Compare that with full replacement (EUR 50,000-500,000+) and the choice is clear. The investment in integration is a fraction of replacement costs — and you have results within weeks instead of months.
Security and compliance in legacy integration
Legacy systems are often the weakest point in security. When integrating, you need to be extra vigilant:
Authentication. Use modern authentication methods (OAuth 2.0, API keys with rotation) for the connection, even if the legacy system itself uses older methods. The middleware layer can handle the translation.
Data encryption. All data flowing between systems must be encrypted (TLS/HTTPS). No exceptions — not even on the internal network.
GDPR compliance. If you synchronize personal data through an integration layer, that layer must be listed in your processing register. The PWA vs. native app discussion also touches on this when apps communicate with backend systems.
Access control. The integration service should only access the data it needs. No admin accounts, no full database access.
Learn more about custom software?
View serviceFrequently asked questions
Next steps
You do not need to replace everything to benefit from AI. Most legacy systems in Dutch SMBs are perfectly connectable — provided you choose the right integration approach.
Start with an assessment: what systems are running, what data do they hold, how accessible is that data, and which AI applications would deliver the most value? That gives you a clear picture of costs, risks, and expected returns — before you write a single line of code.
For a broader overview of integration patterns — not just legacy — read our article on integrating AI into existing systems.
Want to know how your legacy systems can best be connected to AI? Get in touch through our AI consulting service — we will map your system landscape and recommend the smartest integration route.
Learn more about AI consulting?
View service