Complete the series below to get one artefact: A register of limits in which every interface between the old estate and everything built since carries a designated lead, a written direction of travel, a contract reference, and a dated record that it still carries traffic after the last change at either end. An engineer who has never seen the legacy code should be able to use that register to explain what each interface does, who is allowed to call it, and what happens when it breaks.
That register is the deliverable. The steps are how it gets built, and they run in this arrangement because each one removes a way the next one can break.
Integration fixes a gap, and someone must take charge of that gap
OpenLegacy explains that legacy system integration is the practice of connecting older, on-premises systems to newer cloud-based digital technologies, usually through an API platform, and that explanation is accurate as far as it goes. It omits the decision underneath it. Integrating is choosing where the edge between the old system and everything newer will sit, and then managing that edge as a product with a lead, a version and a support role.
The choice is a risk decision. Move the line too far into the legacy core and you inherit the core's release cycle, its undocumented behaviour and its outage pattern. Move it too far into the modern estate and the legacy system keeps its own copy of the truth, and the two copies drift.
The way the work runs follows a specific path.
1. Draw the contract before you read the code
The contract specifies the direction of every message, the payload, the frequency, the latency the consumer can tolerate, and who is permitted to call. SKM Group suggests using the wrapper pattern, which is a modern API layer built around the legacy codebase to keep complexity hidden behind a clean interface. Write it as though the legacy side were a third party you had never met, then hand it to a modern-side engineer. The interface is in the right place if they can build against it without reading the legacy code, and a legacy-side engineer can implement it without knowing who consumes it.
2. Find the traffic you were not told about
Nothing written in the first step survives contact with traffic that was not specified. This step is observation. Confluent says that data format incompatibility tends to be the first hurdle, because legacy systems use proprietary formats that need a transformation layer, and that documentation gaps are common enough that the archaeology has to be deliberate. SKM Group suggests an automated discovery phase that reverse-engineers the codebase to find hidden database triggers and schema dependencies before a single byte moves.
The estate-wide version of the same problem is set out in the GOV.UK guidance on managing legacy technology: organisations often cannot see how their infrastructure evolved, nor disaggregate dependencies away from old technology without interrupting service. Check for an inventory that two staff members have independently agreed, including the file drops and scheduled jobs that no one currently manages. Those are the ones that break a cutover.
3. Move the read path off the transactional core
Reporting, analytics and extract queries are the cheapest traffic to move and the heaviest on the core. A read replica or a change data capture feed gives the modern side its own copy without asking the core to serve it. SKM Group sets this out as direct database integration in read-only form, and the reason to do it first is that it is the one change that improves the core's behaviour instead of adding to it. Confluent's account of integration challenges puts performance bottlenecks near the top of the list, and this step is where they are created.
Check the outcome by measuring the core's load during the reporting window before and after. If the number has not moved, the read path has not moved either.
4. Give the two estates one meeting point
Point-to-point links are fine at two and ruinous at twelve. A managed bus or enterprise service bus gives you one place where routing, retries, transformation and authentication live, and Confluent and OpenLegacy both describe it as the answer for environments holding several disconnected systems. OpenLegacy's account of the alternatives is worth keeping in view: an API is an intermediary with defined rules, point-to-point is custom code between two applications, and a bus translates between many.
The outcome is a count. The number of direct connections between the modern estate and the core should remain stable, and new consumers should be added by configuration.
5. Assign a contact and an exit date to every interface.
An interface without a manager is a future incident. The Cabinet Office digital handbook is direct about the contractual half of this in its commercial guidance on legacy IT: strategic contract management, with clauses that require regular updates and maintenance, and forward planning so that supplier relationships support long-term modernisation instead of quietly extending the life of whatever was bought. The register should carry the support status of everything the interface depends on to ensure the interface's exit date is set before the vendor's own end date.
The check is simple. Each row shows a user and a date. If a row says the platform team, it is not owned.
6. Test the limit by removing one side
Run the test in a controlled window. Make the core unreachable and record what the modern estate does: does it degrade, queue, or lie? Then do the reverse. Confluent's process ends at deployment and monitoring with small deployments first, which is the same discipline at a smaller scale, and the security questions about what crosses the limit are in this test. The outcome is a written statement of behaviour in both directions, with the time to recovery.
Four patterns, and what each one costs you later
Audacia's four approaches for integrating existing software, extending the product, building cross-platform interfaces, aggregating data for business intelligence, and modular refactoring, are compatible and are set out to enable a deliberate choice.
| Pattern | What the modern side may assume | What changes inside the legacy core | Effect on the core's load | The failure it introduces |
|---|---|---|---|---|
| API facade | A stable, versioned contract, with no knowledge of legacy internals | An adapter is added; business logic stays where it is | A small increase per call | The facade itself becomes unowned legacy |
| Read replica or change data capture | Read-only data, eventually consistent | A replication agent and a change log | Read load leaves the core; the write path gains work | Stale reads that no one has agreed a tolerance for |
| Managed bus or enterprise service bus | Routing, retries and transformation are handled centrally | A queue-based adapter at the edge | Bursts are absorbed away from the core | End-to-end timing becomes hard to see |
| Scheduled file exchange | Batch cadence, tolerant of delay | An export that usually already exists | Peaks after hours, on a timetable | Silent failure, because batch jobs fail quietly |
Where integration ceases to be the answer
Integration buys time, and buying time is only worth it when something else is being built with that time. GOV.UK's guidance shows the routes an organisation can take, naming retain, retire, re-host, repurchase and re-platform, and says that the right combination depends on size and infrastructure complexity. Red Eagle's 2026 guide to legacy software modernisation in the UK makes the related point that most organisations should use two or three routes across different parts of the estate as the correct unit of decision.
Those same guidance pages list the blockers that decide whether any route can be delivered: commercial and spending models, financial limits, supplier arrangements and exit strategies, competing priorities, and an institutional aversion to risk that favours a complex hybrid over a clean move. Two of those become thresholds for this page's subject. An integration interface becomes a way of preserving a platform that no one will patch when supplier support for the core has ended, or the contract carrying it is close to expiry. When the knowledge of how the core behaves sits with one or two people, the same applies. The interface is a delay.
Integration that is never revisited accumulates legacy system debt, and the discipline behind retiring legacy system debt applies to interfaces: Find the ones with no clear responsibility, price them, and close them deliberately.
Keeping the register alive
The Cabinet Office handbook defines legacy management as continuous improvement planning, which requires an accurate register of data assets and a current picture of the entire estate as standing obligations. GOV.UK's first principle for managing legacy technology says the same thing in different words: phased and iterative change prevents the accumulation of future legacy technology, and the alternative is a larger decommissioning project later, handled by a smaller set of people who understand it.
The register is therefore not something you hand over and close. It is reviewed on the same cycle as the systems it details, and the review asks one question per row: Is this limit still the cheapest place for the line to sit?
