The decision
Begin by discovering which interfaces the old system actually supports and who is allowed to change it. A modern API can protect new applications from old details, but it cannot make an unreliable source or undocumented business rule disappear. Keep the existing operation understandable throughout the change.
A worked example
For an illustrative warehouse application, inventory is available through a nightly export while order entry uses a supported import. Build an adapter that validates the export, records its age and maps stable identifiers. Show “as of” information to downstream users instead of presenting last night's stock as live availability.
Alternatives worth weighing
- A supported API is usually the first interface to investigate. File exchange can be suitable where delay is acceptable. Read-only database access may help if the vendor permits it and the schema is understood. Screen automation is a fragile option that needs monitoring and a clear recovery owner.
Where the plan breaks
Do not write directly into unfamiliar tables to bypass the application. Start with a reversible read path, reconcile a sample and only then introduce authorised writes. Keep a rollback procedure that describes pending work, not just how to switch off the new endpoint.
Choose the smallest supported boundary
List the old product’s supported exports, imports, reports and extension points before choosing an adapter. Compare them on freshness, permitted write operations, vendor support and operational effort. A file exchange may be entirely suitable for a daily planning task, while an interactive availability promise may require a different source. An API wrapper changes the interface seen by new applications; it does not improve the freshness of the underlying data by itself.
For the illustrative warehouse export, define a file-level contract: expected columns, encoding, unit meanings, snapshot time and a completion signal. Receive the file into a staging area, validate it and publish the new snapshot only when the checks pass. A partially written file should not replace the last complete view. Keep a clear difference between “no stock” and “the latest input has not arrived”; those conditions require different decisions from staff.
Prove that the old operation can continue
Start acceptance with read-only comparisons against familiar warehouse reports. Ask operators to investigate a missing item, an unknown variant and an export with an unexpected quantity unit. Only after those cases are understood should the project introduce supported writes. A write adapter needs permission checks, a durable reference and confirmation from the old system. The new API should report pending work honestly instead of presenting a successful upload as a completed order.
Test disabling the adapter while existing staff continue their established process. Decide what happens to queued imports, whether new requests stop and how work is reconciled when the connection returns. Document the vendor or internal owner who approves interface changes and the person who handles rejected files. Keep examples of accepted and invalid input under version control without personal production data. Those examples make future upgrades reviewable and help a replacement team preserve the business contract, even when the old application itself cannot be substantially changed.
Before you commission the work
Which contract survives a vendor upgrade? How is incomplete input quarantined? Can staff continue when the adapter stops? Bring those constraints to the integration design and judge the result by reliable business records, not the novelty of the API.