A sales portal needs order status, but the legacy application only produces a nightly spreadsheet. Rebuilding the entire application may be unnecessary. Giving the portal direct database access may create a dependency that becomes harder to remove later.
Legacy system API integration creates a controlled way to expose a capability. Its quality depends on clear contracts, permission checks, transaction rules and operational ownership. An HTTP endpoint alone does not establish those boundaries.
Start from a consumer's task
Describe what the consumer needs to do: read an order status, request a price or submit a customer change. Define freshness, response expectations and the business meaning of the result.
Avoid reproducing the database schema automatically. Tables reflect implementation history; a useful API describes a capability the consumer can understand.
For an illustrative delivery portal, “current shipment status” might combine records from several old tables. The API should define which status is authoritative and how delayed updates are represented.
Protect the boundary with an adapter
An adapter can translate identifiers, status values and error responses between the legacy application and new consumers. Keep translation rules documented and tested.
Microsoft's anti-corruption layer pattern describes a translation boundary between systems with different semantics. Apply that idea where exposing old conventions directly would constrain the new application.
Assign the adapter an owner. Decide whether it is temporary or an ongoing interface. Otherwise, a migration shortcut can become permanent infrastructure with no maintenance plan.
Separate reading from changing business state
Read-only access can still expose sensitive information or create load. Apply access controls, return only required fields and measure performance with representative consumer behavior.
Writes need additional care. An insert into an orders table may bypass stock reservation, approval rules or audit events. Use the application capability that enforces those rules, or explicitly recreate and verify them at the boundary.
If a safe write interface does not exist, investigate the workflow before promising real-time integration. A controlled batch exchange may be preferable to an unsafe live update.
Define the contract beyond the happy path
| Contract concern | Question to settle |
|---|---|
| Identity | Which identifier remains stable across systems? |
| Permission | Who may read or change each resource? |
| Validation | How does the consumer correct invalid input? |
| Failure | Can the consumer tell whether work was accepted? |
| Retry | How are repeated submissions recognized? |
| Versioning | How will changes avoid breaking consumers? |
Return meaningful outcomes without exposing database errors or internal details. Preserve a traceable reference so support can follow a transaction across systems.
Make repeated requests safe
A timeout does not prove that a write failed. The server may have accepted it before the response was lost. Blind retries can create duplicate orders or repeated actions.
Microsoft's retry guidance warns about repeated state-changing operations. Define a stable request identifier and application-specific duplicate handling before enabling automatic retries for writes.
Bound the retry policy and distinguish temporary failures from invalid business requests. Retrying a rejected customer code will not make it valid.
Test the complete exchange
Verify identity mapping, permissions, slow dependencies, duplicate messages, partial failures and recovery. Include the legacy system's response when the new consumer sends unexpected volume.
Give operators a way to find stuck work and replay it safely where appropriate. A failed-message list without ownership simply moves the manual workload to another screen.
Our business rules recovery guide helps identify the rules a new interface must preserve.
Choose a bounded first integration
Start with a specific consumer and capability, then prove the contract and operating model before expanding the API surface.
Tranz Technologies' API development and integration service can help define the boundary, mappings and failure behavior. Bring the consumer task and examples of the legacy records it needs to use.
Talk through your software challenge.
Share your existing system, the constraints and what needs to change.
Discuss your project ↗