A useful migration dry run executes the real transformation against an isolated representative set, records every rejection, proves the validation queries, and reverses the result before a production window is approved.
Choose records that exercise the transformation
A convenient sample can pass while the production data fails. The dry run needs ordinary records, missing optional fields, old identifiers, duplicate candidates, maximum lengths, unexpected enum values, and records created by earlier application versions. A source profile should show how often each case appears so the team knows whether the hundred-record set represents a common path or a rare exception.
The source and target schemas establish structure, while the application diff establishes behavior. A field can satisfy the target database constraint and still break a deployed reader that expects the old name or identifier. The dry run therefore includes the application path that will read each transformed record during the compatibility window.
Make every result inspectable
Each source record receives a stable dry-run identifier that connects its original value, transformed value, validation result, and rollback result. Rejected records remain in a separate queue with a reason code. Quietly dropping a row or replacing an unknown value with a default prevents reconciliation because the target total may look complete while the meaning has changed.
Control totals should include more than row count. Teams usually need required-field counts, distinct identity counts, aggregate amounts, date ranges, relationship counts, and a small set of business invariants. AWS describes database migration as an iterative cycle of conversion, migration, testing, and validation, which matches the evidence a dry run should preserve.
Reverse the same change before approving it
A rollback demonstration uses the transformed test copy, not a prose description. It restores the prior readable state, reports any information that cannot be reconstructed, and reruns the old application smoke test. PostgreSQL exposes a check-only upgrade mode for the same reason: compatibility work is safer to identify before the operation changes data. The production gate stays closed until the dry run, validation, and reversal all produce reviewable records.
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.
Sources: AWS database migration phase guidance; PostgreSQL pg_upgrade check documentation.