AI Integration with Legacy Infrastructure

The model is not the hard part

Most organisations that want to use AI are not starting from an empty page. They are running systems that predate the current decade, hold the data that makes AI worth doing, and cannot be switched off while the new thing is built.

This is where AI programmes actually stall. The demo works because it runs against a clean extract someone assembled by hand. Production does not have clean extracts. It has a patient administration system with a SOAP interface documented in a PDF from 2011, a mainframe-era batch file that arrives at 2am, a message queue nobody owns, and a data model where the same customer exists three times under slightly different names.

Connecting a language model to a public API is a week of work. Connecting one to the systems an Australian hospital, agency or bank actually runs on is the engagement.

What integration work really involves

The work divides into four problems, and organisations tend to budget for the first and be surprised by the other three.

Reaching the system. REST where it exists, SOAP where it does not, message queues, file drops, direct database reads where there is genuinely no alternative. Each has different failure modes and different implications for how the AI component has to be designed. A system that can only be read in an overnight batch cannot support a real-time assistant, and that constraint needs to surface in week one rather than month five.

Making the data usable. Real operational data is written by people under time pressure. On a predictive maintenance platform I built for industrial clients, work order text came in with misspellings and inconsistent plural forms that made analysis impossible until they were handled — which meant a Python service for autocorrection and singularisation sitting in front of AWS Comprehend before any model saw the text. That step is invisible in a demo and decisive in production.

Grounding the output. If an AI system is answering questions about your business, the answers have to come from your systems and be traceable back to them. On a production RAG assistant built over a client's own training methodology, the interesting problem was never the chatbot — it was ensuring the assistant could not invent content, because an assistant that invents is worse than no assistant at all. Retrieval design, indexing and citation are the substance of that work.

Operating it. Evaluation, guardrails, cost control and monitoring. An AI feature that works but costs four dollars a query at full volume is not in production, it is in a pilot with the invoice deferred.

Where this has been done

Integration across old and new is most of what I have done for thirty years, well before AI was the reason for it.

At eHealth Queensland, the referral management system delivered across Queensland Health integrates modern Angular and C# services with legacy clinical systems across both REST and SOAP boundaries, with RabbitMQ handling secure, scalable referral submission. It went into production and is still supporting clinical operations.

At Magentus, three years of healthcare interoperability work meant HL7-compliant FHIR APIs adopted across multiple client teams, and Medicare Web Services and My Health Record integrated into the Gentu patient management system. Claims processing cannot pause while you modernise it, so the work had to be additive rather than disruptive, running on AWS Lambda and Docker across Fargate and EKS with infrastructure as code in CloudFormation, CDK and Terraform.

On the Reliability Extranet platform, machine learning analysed factory plant models and work order histories to generate maintenance plans before equipment failed — a serverless pipeline on AWS Lambda and MongoDB Atlas delivered to industrial clients as a production system, with the messy-text handling described above sitting underneath it.

At the University of Queensland, SAML-based federated authentication went into a C#/.NET application and into production, including a mock identity provider built to debug traffic that is otherwise almost impossible to observe.

The common thread is that in each case the new system had to coexist with systems that could not be stopped, changed or fully documented.

A realistic sequence

Where an organisation has AI ambition and a legacy estate, the sequence that works is usually this.

• Look at the interfaces first. Before deciding what the AI will do, establish what the surrounding systems will actually let you read and write, at what latency, and under what access controls. This takes days and routinely changes the plan.
• Pick a use case the integration supports. Not the most impressive one. The one where the data is reachable, the output is checkable, and a wrong answer is recoverable.
• Build the retrieval and grounding layer properly. It is the durable asset. The model in front of it will be replaced within eighteen months; the indexing, access control and traceability will not.
• Put evaluation in before launch, not after. You cannot improve what you have not measured, and you cannot defend what you have not tested.
• Cost it at full volume. Then decide whether it still makes sense.

How to engage

This work is usually either a fixed-scope build — an AI feature inside an existing product, an integration between two systems that refuse to talk to each other, quoted up front with no hourly surprises — or a contract engagement of three to six months where you need a senior engineer who can architect and build without a ramp-up period.

Either way you are dealing with one senior engineer, working inside your review and quality standards, accelerated by agentic tooling but not at the expense of code you have to maintain afterwards.

Related reading:

• integrating AI with legacy systems, a practical guide
• RAG patterns for enterprise AI
• data readiness, the foundation of successful AI
• the free HL7 v2 to FHIR converter
• why most AI projects fail