Compatibility windows across old and new data schemas

List every version that can touch the data

A schema change reaches more than the code in the release branch. Background workers, scheduled jobs, mobile clients, webhooks, support tools, exports, and rollback builds may continue using the prior shape after deployment begins. The compatibility plan inventories those readers and writers, the versions currently deployed, and the last date each old path may operate.

Additive changes are usually the easiest first step. The target field or identifier appears while the old field remains readable, and new code can populate both according to one documented rule. Destructive changes wait until the backfill is reconciled and every required reader has moved. The plan states which representation is authoritative during each stage so dual writes do not create an unresolved conflict.

Measure drift while both paths operate

Dual behavior needs a comparison record. Each write can record the old and new representation, the code version, and whether a readback through both paths produced the same business value. Differences enter an exception queue before the old field is removed. Without this record, the absence of an error only shows that the application accepted the request, not that both states agree.

AWS guidance for migrating database logic recommends running old and new implementations in parallel, comparing results, using feature flags, monitoring both systems, and preserving the ability to revert. Those controls make the compatibility window measurable. They also let the team reduce exposure by moving one workload or cohort before changing every reader at once.

Retire compatibility with evidence

Compatibility code creates maintenance cost, so its removal needs a dated gate. The buyer confirms that the backfill reconciled, rejected rows have owners, old-version traffic has ended, rollback no longer depends on the prior schema, and the new application smoke tests pass. Only then does a later release stop dual writes and remove the old field. The cutover record preserves the evidence so a future engineer can tell why the old path disappeared.

Where the service stops

Reality Contact, LLC prepares and reviews migration code and evidence, but does not authorize production access, operate an unapproved backup, certify regulatory compliance, accept data ownership, or make the final cutover decision. The buyer verifies backups and access controls, approves mappings and thresholds, names the production operators, authorizes the migration window, and runs the approved transformation against production. The service is technical implementation and document preparation, and it does not replace the buyer's database administrator, security review, compliance process, backup ownership, or production authorization. The buyer controls credentials, backups, production execution, acceptance thresholds, and every decision to continue, pause, roll back, or fail forward.