You can usually connect AI to a legacy system without replacing it
Legacy system integration means connecting newer software, here AI agents and workflow automation, to systems that were not built for it. An ERP installed twenty years ago. An on-premise SQL database. Desktop accounting software. A spreadsheet the whole operation depends on. Most of these can be connected without a replacement project.
The approach is the same each time. Find the most stable way into the system that it actually supports. Start by reading, not writing. Give the agent its own account with the fewest permissions that do the job. Log everything it touches. Only then add write access, one action at a time, with a person approving at first.
The ways in, from most to least reliable, are a supported API, a read-only database connection, scheduled file exports, email the system already sends, and screen-level automation. Choose based on what the agent needs to do and what the system and its vendor allow, not on what sounds newest.
Start with the front doors the system already has
Check for an API first, even on old software. Many older ERPs and line-of-business systems have one that nobody on the current team has used. Sometimes it is sold as a separate module or only available on a newer version. A supported API is the best option. It applies the system's own rules, respects its permissions, and is less likely to break when the vendor ships an update.
If there is no usable API, a direct database read is often next. Most on-premise systems keep their data in a standard database. The agent connects through a read-only account, ideally to a reporting copy or a set of views rather than the live tables. This is fast and complete. The catches: the schema is often undocumented, field meanings have drifted over the years, and many vendors do not support writing to the database directly. Writing around the application can skip checks the system relies on. Treat database access as read-only unless the vendor documents a safe way to write.
Talk to whoever administers the system before choosing. They usually know which reports already exist, which tables can be trusted, and which overnight jobs lock records.
When there is no API, use files and email
Almost every business system can export a report. A scheduled export to a secure shared folder gives the agent a regular snapshot to read. Many systems can also import a file in a fixed format, which gives you a controlled way to write. The cost is delay. A nightly export means the agent works from yesterday's data. That is fine for a weekly reorder review and wrong for checking stock during a live call.
Email is another way in. Older systems often send confirmations, alerts and reports by email. An agent can read those messages and pull out the data while the system keeps working exactly as before. This breaks when someone changes the template, so the agent should flag any message it cannot read cleanly instead of guessing.
Screen-level automation is the last resort. Software operates the application the way a person would, clicking through screens and typing into fields. It works when nothing else does, including old desktop software with no export at all. It is also the slowest and most fragile option. A moved button, a new pop-up or a slow screen can break it. Use it for a narrow set of steps, watch it closely, and keep looking for a better path.
Treat a critical spreadsheet as a system of record
In many businesses the real system of record is a spreadsheet. The production schedule. The pricing exceptions. The list of key accounts and their terms. Connecting an agent to it is easy. Keeping that connection reliable is harder, because spreadsheets change shape whenever someone adds a column.
Give the spreadsheet one owner. Fix the structure the agent depends on: column names, the header row, the tabs it reads. Keep version history on. If the agent needs to write, have it write to a separate staging tab that a person reviews and copies across, at least at first. Spreadsheet permissions are coarse, so a staging tab is the simpler way to keep a bad write out of the live data.
If the spreadsheet keeps gaining importance, take note. Integration work often shows which data deserves a proper home.
Read-only first, then earn write access
The safest first release reads from the old system and prepares work for a person. The agent looks up the customer's order history, drafts the order entry, or builds the reorder list. A person checks it and enters it. You learn how accurate the agent is without risking your records.
When the drafts are consistently right, add one write action, usually with approval. Then add the next. Each step should be reversible and tested against real cases, including duplicates and records that are locked or half finished.
Permissions follow the same rule. The agent gets its own service account, never a shared admin login or a person's credentials. It can reach only the tables, screens or folders it needs. Credentials live in a secrets manager, not in a script, and someone owns rotating them.
Every read and write goes in an audit log: what the agent did, to which record, when, from which input, and who approved it. Old systems often have weak audit trails of their own. The integration should not make that worse. When someone asks why an order changed, the log should answer in one lookup.
How to choose the right integration path
Work through four questions. What does the agent need to read, and what does it need to change? How fresh must the data be: minutes, hours or a day? What does the vendor support, and what would break your support agreement? What does a wrong write cost, and how would you find and undo it?
Here is a hypothetical example. A distributor runs an on-premise ERP with no API and wants an agent to draft replies to customer order-status questions. The agent only needs to read, and the data must be current within the hour. A read-only database view of orders and shipments fits, and nothing writes back. If the same business later wants the agent to enter orders, the answer may change to a supported import file, with a person approving each batch.
The right answer often combines methods. A database read for lookups, a file import for writes, and email parsing for the one supplier that only sends attachments is a normal setup, not a compromise.
Where legacy integrations fail and how to catch it
The common failures are quiet. An export job stops running and the agent keeps working from stale data. A vendor update renames a column. Someone adds a status code the agent has never seen. A retry after a timeout creates a duplicate record. A screen automation types into the wrong field after an update, and nobody notices for a week.
Build the checks in from the start. Alert when data is older than it should be. Compare row counts and totals between the source and what the agent read. Give every write a unique key so a retry cannot create a second record. Have the agent stop and flag anything it does not recognize. Run a daily reconciliation between what the agent says it did and what the old system shows.
Plan for the old system's own habits too: overnight batch windows, records locked while someone has them open, and maintenance outages. An integration that works on a quiet Tuesday morning can still fail at month end.
Send us the system you need connected
If an older system holds work an agent could take on, email work@heysigna.com. Name the system and its version if you know it, how your team gets data in and out of it today, and the task you want the agent to handle. That is usually enough to say which integration path fits and what to check first.
