Old is not the problem; closed is
A twenty-year-old system with a documented file import is easier to integrate than a modern one with a locked-down interface.
The question is never the age. It is whether there is a supported way to get data in and out.
Four routes, in order of preference
| Route | Reliability | Maintenance |
|---|---|---|
| Documented API | High | Low |
| Supported file import/export | High | Low |
| Read-only database access | High for reads | Medium |
| Screen automation | Low | High |
File exchange is underrated. A scheduled CSV drop is unglamorous, entirely reliable, and it has outlived a great many fashionable integration platforms.
Read from the database, write through the application
Reading directly from a legacy database is usually safe and fast. Writing directly bypasses the application's own validation and is where data gets quietly corrupted.
Where you must write, use whatever import route the vendor supports, even if it is slower and less elegant.
Screen automation as a last resort
- It works, and it breaks whenever the interface changes
- Budget for ongoing maintenance from day one
- Keep it to a small, well-defined set of actions
- Monitor it actively, because it fails silently
- Plan to replace it as soon as a better route exists
A middle layer helps
Rather than connecting the AI directly to the legacy system, put a small service between them that speaks a clean interface on one side and the legacy reality on the other.
It contains the mess in one place, and it means an eventual system replacement changes one component rather than everything.