Legacy adapters

One adapter, and nothing leaks past it

The rule is simple and constantly broken: exactly one module knows what the old system looks like, and it exposes your types, not its own.

1. ·Inside the adapter: its XML, its date formats, its magic status codes, its five-minute timeouts, its habit of returning 200 with an error in the body.
2. ·Outside the adapter: your domain objects, ordinary errors, ordinary timeouts.
3. ·The test: can you delete the old system and reimplement the adapter against something else without touching anything upstream? If not, its shape has leaked, and it will leak further.

The leak is almost always a date, a status code or a null. Those three account for most of the times we have found a legacy quirk reproduced in business logic four modules away.

What to expect, so you plan for it

It lies about failure

HTTP 200 with a fault in the payload, or an empty result where it means "error". Parse the body, never trust the status alone.

It has no pagination

Or it has pagination that is not stable across pages while data changes. Snapshot first, then page.

Its clock is wrong

Or in another timezone, or in local time with no offset. Normalise to UTC at the boundary and never guess.

It has a hidden rate limit

Undocumented, enforced by getting slower rather than by refusing. Add your own limit below what you have measured.

It cannot be load tested

Because it is shared with a production process nobody will pause. Assume you get one chance at peak and design for graceful degradation.

Make it testable without it

You will not get a test instance. Assume that from the start and the project survives it.

1. 1.Capture real request and response pairs from whatever access you do have, including the malformed ones. These are worth more than any specification you will be handed.
2. 2.Build a fake from those captures that replays them, including the failures and the slowness.
3. 3.Run your entire test suite against the fake. This is what lets you develop on a Tuesday when the system is down for month-end.
4. 4.Run a small contract test against the real thing on a schedule, to catch the day its behaviour changes without notice.

The contract test is what tells you the vendor patched something. On one engagement it caught a date format changing from day-first to month-first, which would otherwise have quietly mis-dated a quarter of postings.

Do not let it set the pace

The most damaging thing a legacy system does is not technical. It slows every decision to the speed of whoever owns it.

1. ·Read through the adapter, write through a queue. Then its downtime delays work instead of failing it.
2. ·Cache reference data locally with a known staleness. A chart of accounts does not need fetching per call.
3. ·Never make it synchronous in a user-facing path. Its p99 becomes yours.
4. ·Write down what you asked for and did not get. When the replacement project starts, that list is the requirements document.