Every AI project in a business older than about eight years arrives at the same wall. The data that would make the thing useful lives in a system that was bought in 2011, sits on a server in the building, is on a support contract that forbids modification, and exposes either nothing or a SOAP endpoint documented in a PDF someone emailed you. AI integration with legacy systems is not an edge case in the South African mid-market. It is the default condition.
There are four ways through that wall. They differ by roughly an order of magnitude in cost and by rather more in how likely they are to break at three in the morning. Getting through it settles only the first of the five connections an AI integration actually involves, and it is the one everyone prices.
What the research actually says, and what it has been turned into
You will see a claim repeated across integration vendors that Deloitte found 60% of AI leaders name legacy system integration as their primary barrier to agentic AI. That overstates it, and the accurate version is more useful.
Deloitte's own published finding is that nearly 60% of the AI leaders surveyed named their primary challenges as integrating with legacy systems and addressing risk and compliance concerns, as a pair, followed closely by a lack of technical expertise. Legacy integration is one of two joint leaders, not the sole barrier. That distinction matters, because the two are usually the same conversation: the reason the old system has no API is often the same reason nobody is confident about what may be done with the data inside it.
Deloitte's Tech Trends 2026 supplies the sharper number. Thirty-eight percent of organisations are piloting agents; 11% have them in production. The gap between those two figures is, in most cases, this wall.
The four ways in, worst to best
Screen scraping and robotic process automation. A bot drives the user interface as a person would. It works on anything, which is its only genuine advantage. It breaks when a screen changes, it runs at human speed, it usually requires a real user licence and a machine left logged in, and it produces no useful audit trail beyond a video. Treat it as a last resort with a deliberate end date, not as an architecture.
Scheduled file exchange. The old system produces a CSV or a fixed-width file on a schedule; you pick it up, parse it, and work from your own copy. Unglamorous, extremely durable, and much better than its reputation. The costs are real and predictable: your data is as fresh as the schedule, you own the parsing when the format shifts, and you cannot write back this way without a matching import route. For a great many AI use cases, reading yesterday's data is entirely sufficient and nobody has ever asked whether it needed to be live.
A read replica or direct database read. If you can get read-only access to a copy of the database, this is usually the best value available. It is fast, complete and stable, and it removes any risk of your workload affecting the production system. Two warnings. The schema is an internal implementation detail, so it will change without notice and without documentation, which makes quality gates mandatory rather than optional. And your vendor's support agreement may prohibit it, so read the contract before you read the tables.
A real API, or a middleware layer in front of one. The right answer where it exists or can be bought. Increasingly, mid-market accounting and ERP vendors have added modern APIs to their cloud tiers even where the on-premise version has none, which converts this from an engineering problem into a licensing decision. That is a much better problem to have, and it is worth pricing the upgrade before pricing the workaround.
Reading is cheap. Writing is where it gets expensive.
The asymmetry is the most useful thing in this post.
Getting data out of an old system, by almost any route, is a bounded piece of work. If it goes wrong you have a bad report and you fix the parser. Putting data back in is a different category of risk entirely: you are now writing to a system of record through an interface its vendor did not design for that purpose, without transactions you control, and often without a reliable way to tell whether the write succeeded.
So the sequencing that works is nearly always the same. Read first, prove the output is right over several weeks of real data, and only then consider writing. Where the write is genuinely valuable, the safest shape is usually that the AI system prepares the change and a person applies it, at least until the error rate is measured rather than assumed. That is not timidity; it is the same read-then-write discipline you would apply to any integration with a system you do not control.
AI integration with legacy systems, in the actual South African case
Three patterns come up repeatedly here and are worth naming because the international writing on this topic does not describe them.
The data is reachable but the meaning is not. You get the tables and discover that the customer master has three spellings of the same company, that a field called status carries eleven values with no documentation, and that a convention agreed verbally in 2018 is holding half the reporting together. This is the same problem we described in everyone in your company is looking at different numbers, and it is why the honest first step is often data foundations work rather than an AI project at all. The Cloudera and Harvard Business Review research we cited in your data is your moat found that just 7% of organisations said their data was completely ready for AI adoption; nothing suggests the mid-market number is better.
The system is fine and the licence is the obstacle. The API exists, on a tier you are not on, or on the cloud version you have not migrated to. This is a commercial negotiation dressed as an engineering problem, and engineering time spent working around it is often more expensive than the upgrade. It is the buy the boring, build the unique decision in a different costume.
Nobody left knows how it works. The person who configured it has gone. There is no test environment. This is the case where the correct engineering decision is to be extremely conservative: read-only, out-of-hours, against a copy, with the original untouched.
When the honest answer is not to integrate
Sometimes it is not worth it, and saying so is the useful thing a supplier can do.
If the task runs a handful of times a month, if the data volume is small enough that a person exporting a file once a week is genuinely fine, or if the only route in is screen automation against a system due for replacement in eighteen months, then the integration is not the value. Build the AI part against a manual data drop, prove it earns its keep, and let the integration follow the evidence. We set out the filter for which jobs justify this at all in AI workflows: how to find the ones actually worth automating, and the reachability of the data is one of the five tests for a reason.
The alternative, and we see it regularly, is six figures of integration work commissioned to serve a workflow nobody had established was worth automating. The prior question, which decision this is meant to change, is where we would rather people began: start from the decision, not the data.
What to ask before you sign
- Which of the four routes is this, specifically? If the quote does not say, the estimate is a guess.
- What happens when the source schema changes? The answer should describe a quality gate that fails loudly, not a promise of vigilance.
- Is this read-only in phase one? If not, why not, and what is the reversal path for a bad write.
- Does our support contract permit it? Ask before, not after. Vendor-prohibited database access is a discovery you want in week one.
- What is the cost if the legacy system is replaced in two years? A file-based integration is nearly free to repoint. A deep bespoke coupling is not.
- What proportion of this estimate is the AI, and what proportion is the plumbing? In our experience the plumbing is the larger share and any quote implying otherwise will be revised upward later, a point we made in AI software development: what actually changed.
None of this is exciting and all of it is where projects at this scale actually succeed or fail. If you want the routes priced honestly against your specific systems before anything is committed, that is what our AI integration scoping work is for.
FAQ
Can AI work with a legacy system that has no API? Yes, through one of four routes: screen automation, scheduled file exchange, read-only database access, or a middleware layer. They differ substantially in cost, fragility and audit quality. Scheduled file exchange and read-only database access cover most mid-market cases well and are far more durable than screen automation.
Is legacy integration really the main barrier to AI? It is one of the two joint leaders. Deloitte found nearly 60% of surveyed AI leaders named legacy system integration and risk and compliance concerns together as their primary challenges, with technical expertise close behind. The frequently repeated version, that 60% named legacy systems alone, overstates the published finding.
Should we modernise the old system before doing anything with AI? Usually not first. A full replacement is a multi-year programme and AI is a poor reason to start one. The pragmatic sequence is to get read-only access by the cheapest durable route, prove value on one workflow, and let that evidence inform the modernisation business case rather than the other way round.
Is it safe to let AI write back into our accounting or ERP system? Not as a first step. Read-only integrations deliver most of the early value at a fraction of the risk. Where a write is genuinely valuable, have the system prepare the change and a person apply it until the error rate has been measured over real data rather than estimated.
How long does this take? Scheduled file exchange or a read replica against one system is typically weeks. Screen automation is faster to demonstrate and considerably slower to stabilise. Anything requiring a vendor licensing change runs on the vendor's timetable, which is why that question belongs in week one.
What if our support contract forbids database access? Then that route is closed and you are choosing between file exchange, a vendor-supplied API on a higher tier, or screen automation. Check the contract before design rather than after, because discovering this late usually invalidates the estimate rather than adjusting it.
References
- Deloitte: AI trends: Adoption barriers and updated predictions (the finding that nearly 60% of surveyed AI leaders named legacy system integration together with risk and compliance concerns as their primary agentic AI challenges, followed by lack of technical expertise). https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/blogs/pulse-check-series-latest-ai-developments/ai-adoption-challenges-ai-trends.html
- Deloitte Insights: Tech Trends 2026 (38% of organisations piloting agents against 11% with agents in production; 42% still developing a strategy and 35% with none). https://www.deloitte.com/us/en/insights/topics/technology-management/tech-trends.html
- Deloitte Insights: Agentic AI strategy, Tech Trends 2026 (legacy system integration, data architecture constraints and governance as the three infrastructure obstacles). https://www.deloitte.com/us/en/insights/topics/technology-management/tech-trends/2026/agentic-ai-strategy.html
- Cloudera and Harvard Business Review Analytic Services: Taming the Complexity of AI Data Readiness (surveyed October 2025, released March 2026; 7% of organisations reporting data completely ready for AI). https://www.cloudera.com/about/news-and-blogs/press-releases/2026-03-05-only-7-percent-of-enterprises-say-their-data-is-completely-ready-for-ai-according-to-new-report-from-cloudera-and-harvard-business-review-analytic-services-reveals.html
Written by JP, Sixees Labs. Last reviewed August 2026.