The hardest part of every enterprise AI deployment we have done is not the AI. It is the legacy system sitting between the AI and the data. ACCPAC installations from 2005. Business Central instances with fifteen years of custom modules. Xero accounts with workflows that nobody documented. QuickBooks databases that have been migrated three times and still have ghosts of data from the original system.
The first instinct everyone has is to replace the legacy system. Do not do this. I have watched companies spend two years and seven figures on ERP replacements that ended in disaster. The legacy system has survived because it works, and because it contains institutional knowledge encoded in its configuration that nobody fully understands. Replacing it is not an AI project. It is a company-wide transformation that will consume all available oxygen.
Our approach is what I call the adapter pattern, borrowed from software engineering. You do not touch the legacy system. You build a layer that sits between it and your AI system. This layer reads data out of the legacy system, transforms it into a format the AI can work with, and writes results back. The legacy system never knows the AI exists.
The adapter is where all the complexity lives. For one client running ACCPAC, the adapter had to handle fourteen different export formats depending on which module the data came from. Some were CSV. Some were fixed-width text files. One was a proprietary binary format that we had to reverse-engineer. The AI model itself took two weeks to build. The adapter took three months.
One critical lesson we learned the hard way: never write directly to a legacy system's database. Always use the system's own import mechanisms, even if they are slow and clunky. We once tried to write directly to a Business Central database to speed up a process. It worked in testing. In production, it corrupted a posting batch because Business Central has internal consistency checks that only run through its own API. That was an expensive lesson.
The data quality problem is worse than you expect. Legacy systems accumulate garbage data over years. Duplicate records, inconsistent naming conventions, orphaned entries, currency format mismatches. Before any AI work can begin, you need a data cleaning phase. We typically budget four to six weeks just for data assessment and cleaning on legacy integration projects. Clients hate hearing this because they think their data is clean. It never is.
API availability varies wildly. Xero has a decent API. QuickBooks Online has a workable one. Business Central's API is comprehensive but Byzantine. ACCPAC, depending on the version, might have no API at all, in which case you are working with file exports and scheduled imports. We have built integrations that run on cron jobs moving CSV files between directories. It is not elegant. It works.
Version fragmentation is another beast. When a client says they use Business Central, that could mean any of five major versions with different capabilities. We had one engagement where two subsidiaries of the same company were running different versions of the same ERP. The adapter had to handle both, which effectively meant building two integrations.
The testing strategy for legacy integrations needs to be paranoid. We run every integration through a shadow period where the AI processes data but does not write anything back. A human compares the AI output to what they would have done manually. This usually runs for four to eight weeks. It catches edge cases that no amount of unit testing will find — things like fiscal year boundaries, multi-currency transactions, and retroactive adjustments.
My biggest piece of advice: treat the legacy system as immutable infrastructure. Do not try to improve it, modernize it, or extend it. Route around it. Build your intelligence layer on top of it. Let it do what it does — store transactions and generate reports — and handle everything else in your own stack. This is not the technically pure approach. It is the approach that actually ships.