Some systems cannot be replaced yet. The budget is not there, the vendor contract has three years to run, or the risk is simply too high this year. That does not mean the business has to wait, because most of what people want from a modern platform is access rather than replacement. They want a mobile app, a partner integration, a customer portal, or an assistant that can answer a question the system already knows the answer to.
An API layer in front of a legacy system delivers that without touching the system underneath. Done well, it also becomes the routing layer for an eventual replacement, so the work is not thrown away. Done badly, it produces a second system that is as hard to change as the first.
Key Takeaways
- An API facade unlocks most modern use cases without replacing the system underneath, and can become the routing layer for a later migration.
- Design the API around business capabilities, not around the legacy system’s internal structure, or you will export its constraints to every consumer.
- Protect the legacy system with rate limiting, caching and circuit breakers. Modern traffic patterns will exceed what it was sized for.
- Prefer read-first. Exposing reads is low risk and delivers most of the value; writes need transaction and idempotency design.
- Batch-only systems can still be integrated, but be explicit with consumers about data freshness rather than hiding it.
Design around capabilities, not around the schema
The fastest way to build a legacy API is to expose the tables and let consumers assemble what they need. It is also the fastest way to guarantee you can never change the legacy system, because every consumer is now coupled to its internal structure.
Design the interface around what the business does. A customer profile, a policy, an account balance, a shipment status. Where the legacy model differs from that, the facade absorbs the difference, joining across the four tables the data actually lives in and translating status codes into meanings. That translation layer is the entire point, and it is what lets the system underneath change later without breaking anything above.
Anti-corruption layer: a translation boundary that converts a legacy system’s model and terminology into a clean domain model, so the legacy design does not leak into new systems built against it.
This costs more upfront than a pass-through, and it is the difference between an integration layer that ages well and one that becomes the next thing needing modernization.
Protect the system underneath
Legacy systems were sized for the traffic they had. A batch window, a few hundred concurrent internal users, predictable load. Putting a customer-facing app in front changes the shape of that traffic entirely, and the failure is usually not gradual.
Four controls do most of the work. Rate limiting per consumer, so one misbehaving integration cannot saturate the backend. Caching for reference and slow-changing data, which typically absorbs a large share of read traffic. Circuit breakers that fail fast when the backend degrades, rather than queueing requests until everything times out. And connection pooling with a hard ceiling, because older systems frequently have low connection limits that are easy to exhaust.
Load test against a representative environment before exposing anything externally. The number that matters is where the legacy system starts degrading, not where the API layer does, and it is usually lower than anyone expects.
Reads first, writes carefully
Exposing reads is low risk, quick to deliver and covers most early use cases. Start there and get something in production.
Writes need more design. The legacy system may have business rules enforced in screen logic rather than in the database, which means a write that bypasses the screen bypasses the rules. It may lack transactional guarantees across the operations your API needs to perform together. It may have no idempotency, so a retried request creates a duplicate record.
Handle this by routing writes through whatever the legacy system considers its own transaction boundary, whether that is a stored procedure, a service module or a supported API, rather than writing directly to tables. Add idempotency keys at the facade so retries are safe. And validate in the facade against the same rules the screens enforce, accepting that discovering those rules is often the largest piece of the work.
When there is no API at all
Plenty of systems offer nothing to integrate with. There are still options, in rough order of preference.
A supported vendor interface, even a dated one such as SOAP or a proprietary connector, is the safest route. Database-level access with a read replica works for reads where the schema is stable and the vendor permits it. Change data capture from the transaction log gives an event stream without touching the application, and works well for keeping a modern read store current. File-based batch exchange remains viable where the business genuinely tolerates the latency. Screen-level automation is the last resort, and it is brittle enough that it should be treated as a temporary bridge with a stated end date rather than an architecture.
Whichever route, be explicit with consumers about freshness. An API that returns overnight data should say so in its contract. Consumers who assume real time and receive yesterday’s figures will build features on that assumption, and the resulting incidents are entirely avoidable.
Make it the foundation of the replacement
The facade you build for integration is the same facade a strangler fig migration needs. If routing is a configuration concern from the start, and consumers only ever talk to the facade, then moving a capability to a new implementation later is a routing change rather than a project.
That is worth designing for even if replacement is years away, because it costs very little now and removes an entire phase of work later. It also strengthens the business case when the time comes, since a large part of the enabling work is already paid for and running.
It also unlocks the capabilities that usually drive the request in the first place. Once a clean interface exists, conversational and automation layers can be built against it without any of them needing to understand the legacy model.
Frequently asked questions
Will an API layer slow the legacy system down?
Only if you let it. Caching typically reduces backend load rather than increasing it, because repeated reads are absorbed at the facade. The risk is new traffic volume, not the layer itself, which is why rate limiting and load testing come before external exposure.
How long does it take to put APIs over a legacy system?
A first set of read endpoints on a documented system usually takes six to ten weeks including security and testing. Undocumented systems take longer, and most of the extra time goes into discovering business rules rather than writing code.
Is this a substitute for modernization?
No, and it should not be sold as one. It buys time and unlocks new channels while the underlying system stays as it is, including its run cost and its risk profile. It is a good decision when replacement is genuinely not viable this year, and a poor one when it is used to postpone a decision indefinitely.
What about security?
The facade becomes a new external attack surface for a system that was probably designed for internal use only. Authentication and authorization belong at the facade, enforced per consumer, with the legacy credentials never exposed. Where personal data is involved, the UAE’s Personal Data Protection Law applies to what the API returns, so field-level filtering by consumer entitlement matters as much as endpoint access.
Can we use this for open banking or partner integrations?
Yes, and it is a common driver. Under the Central Bank of the UAE’s Open Finance Regulation, gazetted in April 2024, licensed banks and insurers must provide data access and transaction initiation to Open Finance Providers, which for institutions on older cores means exactly this pattern: a compliant interface in front of a system that was never designed to offer one.
Need modern channels on an old system?
Kentro builds API layers over legacy platforms for banks, insurers and enterprises in the UAE and GCC, designed so the same layer carries the eventual replacement.
