A 2011 mainframe policy system was finally decommissioned last quarter. The anti-corruption layer built to translate its model is still in the request path, and over 14 years its translated model became the one every downstream service understands - including services written after the mainframe stopped being the source of truth. Sequence its removal.

What has actually happened

The layer has inverted. It was built to protect the new model from a legacy one; now it translates from the current model into a legacy shape that 20 downstream services depend on. The thing being protected no longer exists, and the translation is the only place the legacy vocabulary survives.

This matters for sequencing. You are not removing an adapter; you are migrating 20 consumers off a model, and the layer is the only thing documenting what that model is.

The sequence

1. Extract the layer's mapping into a specification. Field by field, including the default values, the sentinel codes, the date conventions and the special cases. This is the one artefact that must exist before anything is deleted, and it is probably not written down anywhere else. Reversible, costs a week or two, and it is where the surprises are found.

2. Classify every mapping rule. Three buckets: pure renames, genuine business rules that happen to live here, and compensations for mainframe quirks that are now meaningless. Only the third bucket can be deleted outright. The second must be moved somewhere with an owner, and it is the bucket people underestimate — 14 years of "just put this here" accumulates real policy.

3. Publish the modern contract alongside the legacy one. The layer now serves both shapes. Nothing has moved yet and every consumer has a target to migrate to. Fully reversible.

4. Measure consumption per shape, per consumer. Instrument which consumer reads which shape and which fields. You will find fields nobody reads — delete those from the plan — and consumers nobody knew existed, usually a report or an integration running monthly.

5. Migrate consumers one at a time, newest first. Services written after the mainframe died have the least legacy coupling and the most motivation, so they validate the new contract cheaply. Each migration is independently reversible.

6. Shrink the layer as consumers leave. After each migration, delete the mapping rules nobody uses. The layer gets smaller and the remaining consumers become visible.

7. Freeze the legacy shape. No new consumers, enforced in the pipeline or by code review. This is the point of no return in practice: after it, the legacy shape has a known, shrinking population.

8. Delete the layer when the last consumer has moved, and keep the specification from step 1 in version control as the record of what the fields meant.

Where data can diverge, and how you would know

Between steps 3 and 8 the two shapes coexist, which is the risk window. A rule changed in the modern contract and not in the legacy mapping gives two consumers different answers to the same question, with no error anywhere.

Guard it by making the legacy shape a pure projection of the modern one — computed from it, never maintained in parallel — and by running a continuous comparison on a sample of real requests that alerts on any field disagreement. Without that, divergence is discovered in a reconciliation mismatch weeks later, which is the hardest class of defect to attribute.

The rollback at each stage

Steps 1 to 4 change nothing in the request path. Step 5 rolls back by pointing one consumer at the legacy shape. Steps 6 and 7 roll back by restoring deleted mapping rules from version control, which is why they must be deleted in small, separately reverted commits. Only step 8 is one-way, and by then it has no traffic.

How long it really takes

Longer than the original integration did. Twenty consumers at one to three weeks each, run in parallel across teams that have their own roadmaps, is two to four quarters of calendar time for a small fraction of a team's effort. The honest framing for the funding conversation is that steps 1 to 4 are a few weeks and deliver the map, and the rest is opportunistic work attached to each consumer team's existing plans.

When not to do it at all

If the layer is stable, cheap and nobody is blocked by it, leave it. A translation that works, costs a few milliseconds and changes twice a year is not worth two quarters of coordination. The triggers that justify the work are concrete: the legacy shape blocks a feature, its date or identifier conventions are causing defects, or nobody left understands the mapping — which makes step 1 urgent whether or not you ever delete anything.