Legacy Wrapping
Placing a modern interface in front of a legacy system so that consumers integrate with the wrapper rather than with the legacy system directly.
The highest-value first move in most modernisation programmes, because it decouples every future consumer from the legacy system without requiring the legacy system to change.
The wrapper exposes an API, or publishes events, in a model the organisation would choose today — and translates to whatever the legacy system actually offers: a database, a file interface, a message queue, a transaction gateway, or in the worst case a screen interface.
What it buys: new consumers integrate against a stable modern contract; the legacy system's eventual replacement becomes invisible to them; and the anti-corruption boundary prevents decades of legacy modelling from propagating into new services.
That last point is the one that decides whether modernisation succeeds. Publishing raw legacy structures — particularly from a change-data-capture feed, which carries the source's table and column names — makes the legacy model the organisation's permanent public contract.
Design points: the wrapper should be thin, translating rather than accumulating business logic; it should own its own availability characteristics, using caching or queueing so that legacy downtime does not immediately propagate; and it must not permit direct access to bypass it, because the exceptions are what eventually make the migration impossible.