TL;DR & Quick Summary
Connecting AI to a legacy system typically costs about $20,000–$50,000 for a focused, read-only integration, and $50,000–$120,000 or more once it needs write actions, several systems or screen automation. What decides the number is not the AI model. It is how you reach the data: a documented API, a database replica, a file export or a screen.
Read-only, one system: $20,000–$50,000, typically 6–10 weeks
Read and write, two or three systems: $50,000–$120,000, typically 10–16 weeks
Screen automation as the only route: budget more for maintenance than for the build
Biggest hidden costs: data cleaning, access reviews, and the time of the people who know the old system
Key Takeaway: Ask first how the AI will reach the data, then price that route. The question "can AI connect to our system?" is answered by the access method, not by the AI.
Get Started: Want a realistic estimate for your system? Schedule a strategy call with Cogniq AI, or read our AI integration services for legacy systems for the connection options.
Why the Access Method Sets the Price
Integration cost follows the same logic as any software project: people, weeks and rate. What changes the weeks is how much work sits between the AI and the data. Consider the three common routes:
| Access route | What the work involves | Relative effort |
|---|---|---|
| Documented API | Map fields, handle errors, test | Lowest |
| Database replica or export | Understand tables, reconcile records, build a pipeline | Medium |
| Screen automation | Script screens, handle timing and layout, maintain as screens change | Highest per unit of data |
A legacy system with a documented API can be integrated in weeks. The same business logic reached through screens can take months, and it keeps costing money each time the screens change. Before you request quotes, find out which of these routes exists for each piece of data you need.
A Worked Estimate
For illustration, a manufacturer wants a support assistant that answers questions about order status, stock and delivery dates, drawn from a fifteen-year-old ERP.
- Discovery (2 weeks): find the tables behind orders, stock and shipments; check whether a read replica exists; list the fields that matter. Two engineers, about 80 hours.
- Data pipeline (3 weeks): build a nightly copy of the relevant tables into a store the AI can query, with reconciliation checks against the ERP's own reports. About 240 hours.
- Assistant and permissions (3 weeks): retrieval, answer generation with sources, role-based access so staff only see their own plant's data. About 240 hours.
- Testing and rollout (2 weeks): a test set of real questions, a parallel run against the ERP's reports, and training. About 160 hours.
That is about 720 hours. At $60 to $90 an hour, the build comes to roughly $43,000 to $65,000, in the read-only band. Running costs are separate: the pipeline, hosting and model usage are usually modest, but someone must keep the pipeline working when the ERP changes.
If the business later wants the assistant to change orders, add an approval step, a write service through the ERP's own interface, and a second round of testing. That is the step that moves the project into the higher band.
Read Before You Write
The cheapest, safest pattern is to start read-only and earn the right to write. Reading from a replica does not touch the production system's rules or records. Writing is different. A direct database write skips the business rules the ERP enforces, such as credit limits, approval thresholds and stock reservations, and it can leave records that look valid but are wrong.
If the business needs writes, route them through the application's own interface or an approved service layer that applies the same rules. Add an approval step for anything sensitive. Our guide to human-in-the-loop approval gates explains how to design those steps so they are not rubber stamps.
When Screen Automation Is the Only Option
Some systems expose nothing except a screen. Screen automation can reach them, but it is the most fragile route:
- A small change to a screen layout, a new pop-up or a slow network can break it
- It is slower than an API or a query, which limits what the assistant can do in a conversation
- Each change to the legacy system needs the automation to be repaired
If screen automation is the only route, keep it narrow: one task, monitored for failures, with a clear handoff to a person when it breaks. Budget for ongoing maintenance as a permanent cost, not a one-off.
The Hidden Costs
These are the items that most often turn a small estimate into a large one:
- Data cleaning. Legacy records carry years of inconsistent entries: duplicate customers, unit codes that changed, free-text fields used as data. Cleaning is usually the largest unplanned task.
- Access and security reviews. Old systems often have shared accounts, unclear permissions and no audit trail. Fixing that is part of the project.
- Vendor and version changes. If the legacy vendor releases a patch or stops supporting a version, the integration may need rework.
- Testing without risk. Testing on production is not acceptable, so you need a non-production copy, which may need its own setup.
- Expert time. The people who understand the old system are usually the busiest people in the business. Plan their time explicitly, or the project waits for them.
A Phased Plan That Limits Risk
Legacy integrations go best in phases, with a clear decision at the end of each one:
- Map and observe (2–4 weeks). Identify the data, the access route and the people who know the system. Decide whether the first use case is worth building, using a small sample of real questions.
- Read-only assistant (6–10 weeks). Build the replica pipeline and the assistant. Run it alongside existing reports and staff for a few weeks, and measure how often the answers match.
- Controlled writes (4–8 weeks, if needed). Add one write action through the application's own interface, with approval for anything above a threshold. Start with the lowest-risk action.
- Expand on evidence. Add the next data source or action only when the previous step has run cleanly and its failures are understood.
Each phase has its own budget and its own stop point. If the read-only assistant does not earn its place, the business has spent a fraction of the full programme and learned which data matters.
Choosing a Partner for Legacy Work
Many AI firms are strong on modern stacks and weak on old ones. Ask specific questions before you shortlist:
- Which legacy systems have you connected, and by which route? Ask for names of platforms and the access method, not general experience.
- How do you handle a system with no documentation? Good answers describe how they reverse-engineer tables, validate with business users and check reconciliation.
- What happens when the legacy system changes? Look for monitoring, versioned interfaces and a maintenance plan.
- Who on your team has done this before? Ask for the people who would do the work, not only the company.
A partner who answers with frameworks and modern examples only has not done the hard part. For a broader view of partner selection, see how to choose an MVP development company, whose checks on ownership and access apply here too.
Controls such as permissions, logging and approvals add to these figures. Our guide to what AI governance costs with legacy systems shows how to size them.
Should You Replace the Legacy System First?
Usually not, and not as a prerequisite. Replacement is a large programme with its own timeline, cost and risk, and it can take years. A read-only integration often delivers value within a few months. It also reveals which parts of the legacy system the business actually depends on, which makes any later replacement cheaper and better targeted.
The exception is a system that is failing outright. In that case the integration question becomes a replacement question, and it should be priced as one.
How to Get a Realistic Quote
Give potential partners the following before they quote:
- The questions the AI must answer, from real staff or customer requests
- The data behind them, with the tables or screens you believe hold it
- The access you can provide: replica, export, service account, or screen only
- Whether any writes are needed, and which approvals apply
- The volume and the users, to size running costs
Then ask for the access route, the data checks, the test set and the maintenance plan in each proposal. Two quotes with the same scope and different access assumptions are not comparable until those assumptions are explicit.
What Good Looks Like After Launch
A successful legacy integration is measured by reliability as much as by the feature. Track these from the first week:
- Answer agreement: how often the assistant's answers match the legacy system's own reports, sampled weekly
- Pipeline freshness: how old the replica data is when a question is asked, and alerts when a load fails
- Reconciliation exceptions: records that do not match the source, reviewed by someone who knows the system
- Staff use: whether people who used to ask a specialist now get answers directly
Agreement and freshness should be reported to the business monthly. When the legacy system changes, these numbers show the breakage first.
Conclusion
AI integration with a legacy system costs about $20,000–$50,000 for a focused read-only project and more for writes or screen automation. The price follows the access route: an API is cheap, a replica is moderate, and a screen is expensive to keep working. Start read-only, price the data work and the hidden costs honestly, and treat replacement as a separate decision, not a prerequisite.
Schedule a strategy call with Cogniq AI to scope the integration for your system, or explore our AI integration services.
