A new platform must integrate with legacy systems that only support batch file exchange. How should the boundary be designed so the new system is not constrained by it?

The boundary

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

The layer owns every quirk: what status code 7 means, that a blank field means unknown rather than empty, the date format that is nearly standard, the identifier that is unique only within a product line.

Bridging batch to interactive

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

The strangler connection

The projection is also step one of the migration. Once reads are served from your own store, the legacy system is off the read path, and moving writes becomes possible without changing consumers. That sequencing is what makes the eventual migration feasible rather than theoretical.

What to avoid

• Point-to-point integrations from several new services to the legacy system, which multiplies coupling and guarantees all of them change when it does.
• Exposing the legacy model through a new API, which is a legacy system with JSON.
• Real-time integration the legacy system cannot support, capping the new system's availability at a batch window.
• Treating the anti-corruption layer as throwaway. It will outlive the migration and deserves the same engineering standards as the core.

The organisational half

The legacy system usually has one remaining expert. Capturing their knowledge — the undocumented behaviours, the reasons for the odd fields, the failure modes — is a migration activity with a deadline set by their retirement or departure, and it is the input the anti-corruption layer is built from.