An insurance platform must integrate with a legacy policy administration system with a rigid data model and batch-only interfaces. How should the boundary be designed?

The boundary that must exist

An anti-corruption layer, and the discipline is that the legacy model stops there. The moment legacy field names, codes and assumptions appear in the new system's domain model, the legacy system's constraints have become permanent — and they will outlive it.

The layer translates in both directions and owns every piece of knowledge about the legacy system's quirks: the meaning of status code 7, the fact that a blank field means "unknown" rather than "empty", the date format that is nearly ISO, the identifier that is unique only within a product line.

Bridging batch and interactive

The hard mismatch is temporal: the new system wants to answer in milliseconds and the legacy system responds in a nightly file.

• Maintain a read-side projection of legacy data, updated from each batch, so interactive reads never touch the legacy system. This is essential and it introduces a known staleness that must be surfaced.
• Mark data with its as-of time and design the product around it. "Your policy as of last night" is an honest and usually acceptable statement; a silently stale value is not.
• Queue writes for the next batch window, with a clear intermediate state visible to users and staff — "submitted, effective from tomorrow" — rather than pretending the write completed.
• Reconcile after every batch, comparing the projection against what the legacy system actually accepted, because a rejected record in a batch file is the characteristic silent failure of this integration style.

Where the strangler fits

The projection is also the first step of migration. Once reads are served from your own store, the legacy system is no longer on the read path, and the second step — moving writes — becomes possible without changing consumers. That sequencing is what makes a strangler migration feasible rather than theoretical.

What to avoid

• Point-to-point integrations from multiple new services to the legacy system, which multiplies coupling and guarantees that every one of them must change when the legacy system does.
• Exposing the legacy model through a new API, which is a legacy system with JSON.
• Real-time integration where the legacy system cannot support it, producing a new system whose availability is capped by a mainframe batch window.
• Treating the anti-corruption layer as throwaway. It will outlive the migration, and it deserves the same engineering standards as the core.