Adding AI to software you already own

Most Indian businesses that want AI already run software they are not going to replace. There is an ERP the accounts team knows, a hospital system with eight years of records in it, a desktop program from 2011 that does one thing correctly. The proposals they receive tend to assume a rebuild, which is why most of them do not proceed. Usually a rebuild is not necessary. This article covers where AI attaches to a system you are keeping.

The one question that decides everything

Can you read the data, and can you write back? That is the whole feasibility assessment, and it is worth answering before anyone discusses models.

• An API, documented or not, is the easiest case.
• Direct database access, read-only to begin with, is almost as good and very common with on-premise systems.
• A scheduled export to CSV or Excel is enough for a great many useful features.
• Screen-scraping or robotic automation is a last resort: it works, and it breaks whenever the interface changes.

If the answer is yes to any of the first three, you can build something valuable without touching the existing system. Read-only is a good place to start, because it removes the fear that an experiment will corrupt the records the business runs on.

Four places AI attaches cleanly

In rough order of how quickly they pay off.

The 'alongside' pattern is the one we recommend starting with. It needs only read access, it cannot damage anything, and it answers the question the business actually has, which is whether this is useful at all.

In front: capture at the edge

This is the highest-value pattern and the one that requires most care, because it writes. The shape is: information arrives in an awkward form, something structures it, and a human approves it into the existing system.

A purchase invoice arrives as a PDF. Extraction proposes the fields, a reviewer confirms them beside the document image, and the entry is posted into the accounting software that was always going to hold it. The existing system's data model, validations and reports are untouched; what changed is that nobody types.

The same pattern covers dictation. In Healthixio, a doctor's voice note becomes a draft discharge summary that the doctor approves, and the approved text lands in the record exactly as a typed one would. The model removed the typing, not the authority.

Around: a channel the system never had

Older business software was built for a desk. Your customers are on a phone. Adding a channel is often more valuable than adding a feature, and it is additive by nature: the new channel reads and writes through the same interface a staff member would use.

This is how we approached a storefront for ERP customers. Rather than building a separate e-commerce system to be reconciled later, orders are ERP documents from the start, so accepting one produces an ordinary sale bill and stock and GST stay in a single ledger. The lesson generalises: a new channel should write into the existing system of record, never beside it.

Add a channel to the system of record. Never add a second system of record.

When the system is genuinely closed

Sometimes there is no API, no database access and no export, usually with old licensed desktop software. Options then, in order of preference: ask the vendor for an export, which is often possible and rarely advertised; read the underlying data files directly if the format allows it; use the printed or exported output as the input to automation; and only then consider interface automation.

There is a useful halfway house. When we needed to connect laboratory instruments that could not reach cloud software, we put a bridge on the laboratory network that receives messages locally and forwards them outward. The instruments stayed exactly as they were and nothing inbound had to reach them. Closed systems can often be surrounded rather than opened.

A sensible sequence

1. Establish read access, even if it is a nightly export.
2. Build one read-only feature that answers a question people ask daily. Ship it in weeks.
3. If it earns its place, add a capture-and-approve feature that writes back.
4. Only consider replacing the underlying system once you know which parts of it anyone actually uses.

That last point is the quiet benefit. A year of attaching things to an old system teaches you precisely which of its features matter, which is the information a replacement project normally lacks and the reason so many of them fail.

Frequently asked questions

Can I add AI to my existing ERP without replacing it?

Usually yes. The deciding question is whether you can read the data and eventually write back, through an API, direct database access or even a scheduled export. With read access alone you can build genuinely useful features that cannot damage anything, and a capture-and-approve step can later write into the ERP the same way a staff member would.

What if my software has no API?

Try, in order: ask the vendor for an export, which is more often available than advertised; read the underlying data files if the format permits; use the system's printed or exported output as an automation input; and only then consider interface automation, which works but breaks whenever the screen changes. A bridge that surrounds a closed system is frequently easier than opening it.

Is it risky to connect AI to my production database?

Start read-only and the risk is small. A read-only connection cannot corrupt records, which also removes the organisational fear that blocks most experiments. When you do add writing, route it through a human approval step and through the same validations the existing system applies to manual entry, rather than inserting directly into tables.

Should I replace my old system or build around it?

Build around it first. Attaching features for a year teaches you which parts of the old system people genuinely use, which is exactly the information replacement projects usually lack and the main reason they overrun. Replace once you can describe the real requirement rather than the documented one.