Coexistence

Coexistence is the period in which an old and a new system, or an old and a new path through a system, operate at the same time before and around a cutover. It exists to compare, to move work gradually, or to keep a way back. In a migration it is unsafe unless someone has written down which system is authoritative for each kind of record and action at each stage; that record is necessary, but it does not by itself make coexistence safe.

Authority, side effects, and the comparison point

In a fictional reporting change, the order database remains the authority for every order and receipt throughout; the old report is the approved output and the new path produces a candidate for comparison only. The candidate path must not send notifications, grant approvals, or execute transactions, or the comparison creates duplicate real actions. That is the same rule that governs shadow testing of a model.

Two outputs are comparable only if both read the same data position: the same frozen snapshot, or changes applied up to the same agreed position. If the old job read at 06:00 and the new one at 06:20, a difference may be twenty minutes of new receipts. AWS documents the same limit for its migration validation: rows that are continuously modified during comparison cannot be validated. Freshness of the new path is a separate check.

Two writable systems are the hard case

Replacing a read-only report is lower-risk than replacing a system that accepts transactions. Assign write authority by record or group of work. For data that must remain on both sides, every accepted insert, update, and delete after the initial copy must propagate in the agreed direction. This need not mean bidirectional replication of all data. Synchronization lags, the same record can change in both places, and a retried transfer can apply a change twice unless the transfer is idempotent. Writing to both systems does not provide consistency, because one write can succeed while the other fails, and change data capture gives access to changes without guaranteeing that every destination applied each one once and in order.

Enforce a single writer per group where that is the design; if both systems may update the same record, define how conflicts are resolved. Before the first record moves, define the identity rule, ordering, delete handling, and reconciliation, and budget for the cost and attention that running both paths requires. In a migration, coexistence is meant to end, so set an end date or a review date; a parallel run that nobody closes becomes two systems to maintain.

References

• AWS DMS: Data validation

Examples here are illustrative.