Legacy system integration allows established platforms to support new applications and services while continuing to operate. It can preserve valuable business capability for the long term or enable functionality to move progressively into a replacement system.
Controlled interfaces make this possible, but their design must account for the dependencies, business rules and data flows on both sides. Poorly designed integration can spread complexity across APIs and middleware, create inconsistent records and make future changes harder to deliver.
For technology leaders in financial services, government and other environments with demanding assurance requirements, the task is to maintain service continuity, protect data and make activity traceable as systems evolve.
That requires clear data ownership, defined behaviour during delays or interruptions, auditable access and accountable operational support. These controls help make critical systems safe to change.
What is legacy system integration?
Legacy system integration connects an established system to newer applications, platforms or data services while the existing system remains operational.
It may combine APIs or façades, messaging, translation layers, file transfers and scheduled batch processes. Change data capture can expose changes in stored data, while business events communicate defined occurrences, such as an instruction being accepted or a payment completing.
The integration may support a retained platform or provide a transitional connection as capabilities move to a replacement. Its design should reflect the expected lifespan, the business behaviour that must be preserved and the responsibilities of each connected system.
Our guide to legacy software modernisation versus replacement covers how to decide the platform’s longer-term future. The Strangler Fig pattern describes progressive replacement, which may use integration boundaries to support co-existence during delivery.
In either case, integration must establish how information and instructions pass between systems, what each exchange means and how its outcome will be confirmed.
Why legacy system integration is harder in regulated environments
Connecting a legacy platform to a new application or service changes its operating conditions. It may introduce new users, higher transaction volumes, different response-time expectations and additional dependencies across security, data integrity and service availability.
For financial services firms within scope, the FCA’s operational resilience rules require firms to identify important business services, set impact tolerances and be able to remain within those tolerances during severe but plausible disruption. The PRA’s SS1/21 sets expectations for firms within its scope. Integration design and testing should account for how connected systems support those services.
Government organisations have their own assurance requirements and guidance. The UK Government’s Legacy IT Risk Assessment Framework assesses the likelihood and impact of legacy-related risks, including dependencies that make systems difficult to improve. It provides a basis for assessing risk rather than prescribing a particular integration solution.
These contexts require evidence about how the connected service operates. Establish who owns the data, how permissions are enforced and what happens when a system is unavailable or an exchange only partly completes.
Define how delayed or inconsistent transactions will be detected, how their status will be confirmed and who is responsible for resolving them. Monitoring and audit records should allow teams to trace activity across systems and demonstrate that the service continues to meet its requirements.
Legacy system integration starts with dependency mapping
Before selecting an integration approach, establish how the legacy system supports the business and how changes could affect connected services.
Map:
- the business services and users that rely on the system
- applications that send instructions or data into it
- systems that consume its outputs
- business rules and validation performed within it
- scheduled jobs that update or extract data
- identities, service accounts and access permissions
- manual checks, reconciliation and exception handling
- downstream processes that depend on timing or sequencing
Validate the map against the running system and the people who operate it. Architecture diagrams may omit an overnight file feeding regulatory reporting, a daily reconciliation process or a downstream job that assumes another process has completed.
Record the owner, purpose, timing and service requirements of each critical exchange. Identify which dependencies are confirmed and which need further investigation.
For financial services firms within scope, the FCA’s operational resilience guidance addresses mapping the people, processes, technology, facilities and information needed to deliver important business services, including their dependencies and interconnections.
Where those dependencies or the appropriate intervention remain unclear, our Modernisation Readiness Review helps assess the existing system and options against business requirements.
Use the map to define the integration boundary, identify affected services and plan the tests needed before introducing change.
Choose the legacy integration approach to match the requirements
Select the approach according to the functions the legacy system can expose, the speed and meaning of each exchange, the service requirements and the expected period of co-existence.
The approaches below can be combined. An API façade, for example, may use a translation layer to interpret legacy business rules and messaging to process instructions asynchronously.
| Integration approach | When to consider it | What needs to be established |
|---|---|---|
| API wrapper or façade | Existing functions remain valuable but need a suitable interface for new consumers. | A stable interface, clear request and response meanings, access controls and limits that protect the underlying system. |
| Anti-corruption layer | Systems use different business models, terminology or conventions. | Explicit translation rules, ownership of those rules and tests confirming that business meaning is preserved. |
| Messaging and integration middleware | Exchanges need asynchronous processing, routing or co-ordination across systems. | Delivery guarantees, ordering requirements, duplicate handling, controlled retries and behaviour when consumers are unavailable. |
| Change data capture | Consumers need updates from changes in stored data. | Which changes are captured, how transaction boundaries are represented, acceptable latency and how missed or duplicate updates are detected. |
| Business-event integration | Consumers need to respond to a defined occurrence, such as an instruction being accepted or a payment completing. | The event’s meaning, when it is published, its relationship to committed business state and how ordering and duplicates are handled. |
| File or batch integration | Scheduled exchanges meet the business requirement and fit the legacy system’s operating model. | Completion windows, file validation, partial-processing detection, reconciliation and conditions for safely repeating processing. |
A database change may represent only part of a business transaction. Confirm what consumers can infer from it before using it to trigger further activity.
Use the dependency map to assess the chosen combination, including its effect on the legacy platform’s load, data consistency and operational support. Document interface contracts and ownership so each component can be tested and changed with its consumers in mind.
When API wrapping legacy systems makes sense
API wrapping is worth considering when the underlying system provides valuable business functions but lacks a suitable interface for new applications or services.
GDS API guidance recognises that APIs may need to be built around legacy systems. It recommends designing around consumer needs and separating the resources exposed by the API from underlying data structures where possible.
Define the operations consumers need, what each response means and how much demand the legacy system can support. Exposing internal tables or conventions directly can make every consumer dependent on implementation details that are difficult to change.
Document the interface contract, including validation, response behaviour and compatibility requirements. Test changes with affected consumers and agree how new versions will be introduced and superseded versions retired.
A well-designed wrapper provides a stable boundary while allowing the implementation behind it to evolve.
Legacy integration and the anti-corruption layer. Preserving business meaning
Connected systems may use different definitions, identifiers, status codes or business rules. An anti-corruption layer translates between those models so each system can retain its own conventions.
Microsoft’s guidance on the anti-corruption layer describes a façade or adapter between systems with different semantics. It highlights transaction and data consistency, observability and the need to decide whether the layer will be maintained or eventually retired.
Make translation rules explicit and assign ownership. Test how values, states and exceptions are interpreted, including cases where there is no direct equivalent between the systems.
Keep the layer focused on translation. If it takes responsibility for wider business decisions, establish whether those responsibilities belong there and how they will be maintained. Uncontrolled accumulation of business logic can make the integration harder to understand and change.
Our Strangler Fig guide covers translation boundaries during progressive replacement. For retained systems, the same boundary needs ongoing support, monitoring and review for the full period of coexistence.
Design legacy integrations for delays, interruptions and partial completion
Define how each integration will behave when processing is delayed, a connected system is unavailable or an exchange only partly completes.
Test scenarios such as:
- the legacy system responding more slowly than the consuming service expects
- a transaction completing but its acknowledgement being lost
- the same message arriving more than once
- an instruction being accepted while the receiving system is unavailable
- reconciliation identifying different values across systems
- a batch process completing late or processing only some records
A missing acknowledgement does not establish that a transaction failed. Confirm its status before repeating an operation that could create a duplicate payment, record or instruction.
Specify timeouts, queue limits and controlled retry rules. Where retries are appropriate, use identifiers and duplicate detection so repeating a request does not repeat its business effect.
Define how incomplete or inconsistent outcomes will be detected, reconciled and corrected. Assign responsibility for alerts and exceptions, including any manual intervention, and establish what users will see while processing remains pending.
For financial services firms within scope, the FCA’s operational resilience guidance addresses testing severe but plausible disruption scenarios and demonstrating the ability to remain within impact tolerances.
Use those scenarios to validate the operating procedures as well as the software. Confirm that teams can trace each instruction, establish its outcome and resolve outstanding issues before further processing proceeds where required.
Legacy system integration in practice. Improving component reliability
Following the consolidation of multiple legacy systems, a global network provider experienced severe platform instability. Our published case study identifies poor integration, weak error handling and fragile interaction between components among the problems.
We reduced unnecessary communication between components, introduced defined error scenarios and strengthened testing as part of a wider stabilisation programme. The published results included message failures falling from 12% to 0.3%.
The engagement demonstrates the importance of testing how connected components behave under operational conditions. Integration work needs defined error handling, monitoring and support ownership alongside the interfaces themselves.
Legacy system integration security. Control access and make activity traceable
Connecting a new service to a legacy platform creates additional routes to its functions and data. Define who can use each operation, what information they can access and how those permissions will be enforced.
Apply authentication, authorisation, input validation and traffic controls appropriate to the interface. Check access to individual records and operations, including requests made through service accounts.
The GDS API technical and data standards address authentication, resource-level access controls and authorisation on each request. They also specify logging when personal or sensitive data is supplied and who receives it. OWASP’s API Security Top 10 identifies broken authentication and broken object-level authorisation as significant risks.
Design monitoring, tracing and audit records for distinct purposes:
- Operational monitoring identifies delays, errors, queue growth and reconciliation exceptions.
- Transaction tracing follows an instruction across systems, using correlation identifiers to connect processing steps.
- Audit records establish who performed an action, what occurred, when it happened and its recorded outcome.
Assign owners for alerts and exceptions, and define who can authorise corrections. Protect logs against unauthorised access and alteration, set appropriate retention periods and avoid recording credentials or unnecessary sensitive payloads.
Test that the records allow teams to investigate an exchange and establish its outcome. For delayed or asynchronous processing, distinguish acceptance of an instruction from completion of the business operation.
These controls strengthen the integration boundary. Unsupported components, vulnerabilities and dependencies within the legacy platform still require assessment and management.
Legacy system integration. Define data ownership and batch timing
Connected systems may hold different versions of the same information, particularly when updates arrive at different times. Define which system is authoritative for each critical data domain and how consumers should interpret its status.
For example, a new application may capture customer details while the legacy platform processes transactions. A reporting service combines both, but an overnight update may change records after they have been consumed. The integration needs to distinguish pending information from confirmed business state.
For each critical data domain, document:
- the authoritative system and any ownership boundaries at record or field level
- which systems can create or update information
- how changes are validated and propagated
- acceptable delay and how freshness is communicated
- how discrepancies are detected and reconciled
- who owns exceptions and can authorise corrections
- how ownership will transfer, if planned
An API around a batch-oriented platform still depends on that platform’s processing schedule. Make clear whether a response represents the latest confirmed state, a pending instruction or information awaiting a scheduled update.
For each batch process, define its expected start and completion times, downstream dependencies and the action required if it is delayed or incomplete. Monitor completion and reconciliation, rather than assuming a scheduled start means the work succeeded.
Where records need reprocessing, establish how completed items are identified and how duplicates will be prevented. Test these procedures alongside the batch process so teams can resolve exceptions and continue processing with confidence.
Legacy system risk. Recognise when the integration layer needs attention
An integration layer should provide a manageable boundary around the legacy system. Review whether it continues to support that purpose as consumers, business rules and data flows change.
Signs that warrant investigation include:
- business logic accumulating in middleware without clear ownership
- new interfaces duplicating existing exchanges or creating tightly coupled dependencies
- transitional components remaining in service without a retirement plan
- unclear authority over data and reconciliation
- integration changes requiring extensive coordination across consumers
- delays or interruptions in the integration layer affecting critical business services
These signs may justify simplifying interfaces, clarifying responsibilities or changing the integration architecture. Where the underlying platform remains the main constraint, reassess its longer-term treatment alongside improvements to the integration layer.
Include the commercial impact in that review. Additional engineering effort, manual reconciliation, service disruption and specialist support can increase the cost of operating the estate. Our guide to calculating technical debt in financial terms explains how to assess these costs.
Assign an owner and review point for each important integration. For retained components, maintain the contracts, tests and operating procedures. For transitional components, track the dependencies that must be removed and the evidence required for retirement.
Seven questions to answer before integrating a legacy system
Use these questions to review the proposed architecture before approving implementation. Support each answer with evidence, named owners and any tests still required.
| Question | What the answer should establish |
|---|---|
| 1. Which business services depend on this integration? | The affected users and processes, service requirements, acceptable disruption and dependencies that need testing. |
| 2. Which system is authoritative for each critical data domain? | Where records are created and updated, how changes propagate and who resolves discrepancies. |
| 3. Which business behaviours must be preserved? | Required rules, validation, sequencing and batch behaviour, with tests demonstrating that the integration respects them. |
| 4. How will the service operate during delays, interruptions or partial completion? | Pending states, queue limits, controlled retries, duplicate prevention and communication to users and support teams. |
| 5. How will access and sensitive data be controlled? | Authentication, authorisation, service-account permissions, data protection and protected audit records. |
| 6. How will transaction outcomes be traced and reconciled? | Monitoring, correlation identifiers, completion checks, exception ownership and authorised correction procedures. |
| 7. How will the integration be maintained, changed or retired? | Whether it is retained or transitional, who owns it, how interface changes are tested with consumers and what would trigger retirement. |
Record unresolved assumptions and assess whether they affect the proposed design or service requirements. Assign the investigation or test needed to resolve each material uncertainty before proceeding with the affected work.
The review should produce a clear implementation scope, operational responsibilities and acceptance criteria for controlled delivery.
Legacy system integration that supports future change
A well-designed integration boundary allows valuable legacy capability to remain in use while new services are introduced. It may support a retained platform for years or enable selected functions to move progressively into a replacement.
Our guide to modernising legacy systems with minimal disruption explores how this work fits into change across the wider estate.
Make your critical systems safe to connect and change
Tell us which systems need to connect, what business service they support and what is making the change difficult. You don’t need a complete architecture assessment to start the conversation.
Our Legacy Systems service uses targeted proofs of concept, Minimum Viable Replacements and controlled integration approaches to help validate the engineering decisions before wider delivery.
Talk to Catapult CX about your legacy systems
Frequently asked questions about legacy system integration
What is legacy system integration?
Legacy system integration connects an established system with newer applications, platforms or data services while the existing system remains operational. It may combine APIs, messaging, translation layers, change data capture and batch processes. The design depends on the business requirements, dependencies and expected period of co-existence.
What is API wrapping for legacy systems?
API wrapping provides an interface through which other applications can use existing functions or data. It should define stable operations and clear responses while limiting consumers’ dependence on internal implementation details. Access controls, capacity limits and compatibility testing help protect the platform as usage evolves.
What is an anti-corruption layer?
An anti-corruption layer translates between systems that use different business models, terminology or conventions. It helps preserve the meaning of exchanged information without requiring each system to adopt the other’s model. Translation rules need clear ownership, tests and ongoing maintenance.
How do you reduce risk when integrating systems in a regulated environment?
Map the business services and dependencies, then define data authority, access controls, transaction handling and operational ownership. Test delays, interruptions, duplicates and partial completion. Retain the monitoring and audit evidence needed to trace outcomes, resolve exceptions and demonstrate that the service meets applicable requirements.
How does change data capture differ from business-event integration?
Change data capture identifies changes in stored data. A business event describes a defined occurrence, such as an instruction being accepted or a payment completing. A database update may represent only part of a business transaction, so establish what consumers can infer before using it to trigger further activity.
Can an API make a batch-oriented legacy system operate in real time?
An API can provide access to the system, but the underlying processing schedule still determines when information becomes available or an instruction completes. Responses should distinguish confirmed state from pending processing and make data freshness clear.
When should a legacy system be integrated rather than replaced?
Integration may be appropriate when the platform still meets business requirements and a manageable boundary can support new services. Compare the full cost and risk of maintaining that arrangement with modernisation or replacement. Integration can also support progressive replacement where capabilities can be separated and tested in stages.
How do you prevent duplicate transactions across connected systems?
Use stable transaction identifiers, duplicate detection and controlled retry rules. Confirm the outcome of uncertain requests before repeating operations that could create another payment, record or instruction. Where transactions span systems, define reconciliation and exception procedures to resolve incomplete outcomes.
