Integrate a legacy system when a supported, controlled interface can deliver the required workflow without replacing the whole application. First verify access, data meaning, ownership and operating constraints. Integration can buy useful capability, but it will not automatically remove the limitations or maintenance obligations of the system that remains.
Let’s plan your legacy integration options.
Bring your workflow, constraints and open questions. We’ll help you define the scope and work through the next decision.
Describe the missing capability precisely
Replace a broad request to modernise the system with a business journey: for example, let authorised staff check order status in a new portal without changing how the legacy application posts invoices. That statement identifies a boundary and makes a read-only first release possible.
Ask which changes are genuinely necessary in the old system. A new interface may only need a supported export or API. A workflow that writes stock or financial records has a different risk profile and may require an interface the legacy vendor does not provide.
Compare interface options openly
| Interface option | Useful when | Constraint to investigate |
|---|---|---|
| Supported API | Required operations are exposed and maintained | Authentication, limits, versions and licences |
| Scheduled file exchange | Delay is acceptable and records can be reconciled | Format ownership, partial files and replay |
| Read replica or approved reporting view | Read-only reporting is the goal | Freshness, schema changes and access scope |
| Controlled user-interface automation | No supported interface meets a bounded need | Fragility, credentials and vendor permission |
| Direct database writes | Only where explicitly supported and understood | Business rules, integrity and support consequences |
This table is a discovery aid, not a recommendation to bypass vendor controls. Confirm permitted access and support implications before committing to an integration path.
Use a boundary that contains legacy assumptions
Keep the old system's codes, field meanings and failure states behind a documented interface. New product components should not each reinterpret those quirks independently. Record mappings and retain source references so a support person can trace a result.
Define timeouts, stale-data behaviour and a manual fallback. If the legacy service is unavailable, users need to know whether a displayed status is current, delayed or unknown. Avoid showing a cached value as a confirmed live answer.
Prove the riskiest interaction first
Test an authorised representative transaction with realistic permissions and volume. Check what happens when the source rejects input, changes its schema or becomes unavailable. Include reconciliation for any writes, especially when the destination cannot confirm a timed-out operation.
If no safe interface exists, compare a limited process change with a staged replacement. The legacy modernisation guide covers the broader refactor, replatform and rebuild decision.
Legacy integration questions
Is integration always cheaper than rebuilding?
No. Include interface work, licences, ongoing support and future changes. A brittle connection can carry substantial operating effort.
Should we expose the old database directly to the new app?
Only under a reviewed access design and a supported contract. Shared credentials and uncontrolled schema dependencies make responsibility and change management difficult.
Bring the required journey, vendor documentation and known restrictions to an API development discussion. Verify feasibility before promising a new portal or mobile app around an untested connection.
