You don’t need to replace your system to use AI - you need a way in

If you've had a conversation about AI in the last year, there's a good chance someone has told you — a vendor, a consultant, maybe someone on your own team — that to actually use it properly, you'll need to replace your core system first. The old one's too old, too rigid, not built for it. Time for something modern.

Sometimes that's true. Often, it isn't, and it's worth being able to tell the difference before you commit to a project that size.

Kowhai tree in bloom, Geraldine, South Canterbury

The two things getting bundled together

"Replace your system" and "get AI capability" are being sold as one decision, but they're actually two separate questions. The system you have today might genuinely be past its useful life — that's worth assessing on its own terms. But AI capability specifically doesn't depend on how new or shiny the system is. It depends on one concrete thing: can data get in and out of it programmatically, without a person clicking through the interface by hand?

If the answer is yes, most of what people assume requires a replacement doesn't.

What "a way in" actually means

The cleanest version of a way in is an API — a defined way for other software to ask a system for data, or tell it to do something. If your system has one, even an old and sparsely documented one, something else can be built to work with it, through the same logic and safeguards the system already enforces.

An API isn't the only possible way in, especially for older, on-premises systems. Direct access to the underlying database, scheduled exports, or purpose-built middleware can sometimes work too — though those routes generally bypass the validation the application itself would normally apply, so they carry more risk of leaving data in a state the system wasn't built to handle. An API is usually the safer route, but it's not the only door.

None of this depends on the system being new, cloud-based, or good-looking. On-premises systems can often still be reached from cloud-based tools through a small piece of gateway software, so "it's on our own server" isn't the dead end people assume. And nobody needs to touch the old interface at all if there's a way in underneath it.

What that way in is actually for

To be specific about what this unlocks: it's rarely a case of pointing an AI tool directly at your live core system and asking it questions. For anything resembling real analysis, you'd normally build a regular, reliable extract out of the old system into something purpose-built for that — a proper analytics layer, not the transactional database itself. The "way in" is what makes that extract possible in the first place. Whether what sits on top is a mobile app for a field team or an AI layer built on top of an analytics store, the foundation is the same: something that reliably gets data out, and does something more useful with it than the old system ever could on its own.

That distinction matters for a second reason too. Creating a financial transaction, for example, isn't something I'd hand to an AI tool — you want that process deterministic, the same inputs producing the same result every time, with no room for a model's judgement. AI belongs on the reading and reasoning side of the line, not the writing side, especially where money's involved. Where it earns its keep is surfacing what's already buried in a system that's been running for fifteen or twenty years: records split across modules that were never designed to talk to each other, information that technically exists but takes real effort to find. Making sense of that mess is exactly what reasoning and judgement are good at, and exactly what's slow and error-prone for a person to do by hand.

Proof it works even when the old system is a mess

I want to be upfront that "has a way in" doesn't mean "has good documentation," "will be easy," or "will let you do everything you'd want." Most systems running for fifteen or twenty years have APIs that were never a priority to document, because nobody expected to need them for anything beyond what the system already did.

I ran into exactly that with Shaw's Wire Ropes, who'd been running an ERP called Greentree since the early 2000s — heavily customised, still doing its job, but with a field team it was never built to support. Building a mobile app that talked to Greentree meant working through an API with minimal documentation: trial and error, real constraints on what the API would actually let us do, and a coded workaround for the way it handled bundled service parts.

None of that stopped it from getting built. If a twenty-year-old, barely documented, on-premises ERP can be bridged to a modern mobile app, "our system can't connect to anything new" often isn't true either — and the same principle holds whether what you're connecting is a mobile app or an AI layer.

What to actually ask, before you sign anything

If someone's telling you that using AI properly means replacing your core system, the useful response isn't to take their word for it or dismiss it outright — it's to ask a narrower, more concrete question: is there a way to get data in and out of what you already have? That's usually something you, or whoever manages the system, can find out quickly.

Your current system staying in place should always be one of the real options on the table when a replacement is being proposed — not a sentimental attachment to what you know, but a genuine alternative worth pricing against the disruption, cost, and lost customisation that a full replacement brings with it. Sometimes replacement really is the right call. But "we need this to use AI" shouldn't be the reason that tips the decision, when a bridge to what you already have might get you there for a fraction of the cost.

We use the AI Contribution Scale defined by Blair Enns to disclose the use of AI in our written content.  This article is rated as: AI-4: AI Drafted. The content was drafted by Claude from our own content and ideas, we then refined the output.