How to Share Data and Ensure Consistency Between Old and New Systems During Parallel Migration

When migrating a legacy system, the strangler pattern is often used to replace the old system gradually. During the transition the old and new systems must run in parallel, which raises the problem of how to synchronize and share data while preserving consistency.

In this parallel phase the two systems should keep independent databases; direct cross‑database access is prohibited. Interaction is achieved through public APIs or a dedicated anti‑corruption layer, combined with asynchronous synchronization, event‑driven mechanisms, or dual‑write approaches for high‑real‑time requirements.

Independent databases : Each system owns its own database. If the legacy system is a third‑party product that cannot be modified, it must be accessed only via its public API or an adapter layer.

Write strategy : Use “write‑old‑read‑new” or “dual‑write + compensation”. Early in the migration, writes go only to the old system; the new system listens to the old database’s change logs (Binlog/Redolog) and asynchronously syncs data via Kafka or scheduled batch jobs. When both systems must handle writes, dual‑write is required: writes are sent to the target database and also published to a message queue; the other system consumes the queue to keep data in sync. Such setups need transaction compensation or an eventual‑consistency pattern such as Saga.

Read routing : An API gateway or façade decides, based on request attributes (path, parameters, user tags), whether to call the old or new system. If the new system lacks the needed data locally, it can fetch it synchronously via HTTP/gRPC from the old system or asynchronously via pull‑plus‑cache, achieving eventual consistency.

Anti‑corruption layer : Introduce a conversion layer that maps fields, transforms formats, and aligns business semantics between the old and new data models, preventing the legacy system from contaminating the new architecture.

Autonomy first : Prioritize the new system’s independence and tolerate brief inconsistencies. Synchronization logic must be observable, retryable, and rollback‑capable. Once a migrated module shows stable metrics, its dependencies are switched entirely to the new system.

The ultimate goal is to let the new system progressively replace old functionality while the data flow is peeled off incrementally with each functional iteration. This approach dramatically reduces development cost and risk compared with a full‑scale cut‑over; full data sync is only suitable for the cold‑start phase, while production relies on incremental sync and interface contracts.