Backfill reconciliation compares a fixed source snapshot to the accepted target state through several independent control totals, then explains every difference in an exception record.
Freeze the comparison window
A source count and target count mean little when the source keeps changing between queries. The reconciliation record names the source snapshot, cutoff timestamp, included tables, excluded records, and change-data-capture position. If writes continue during the backfill, the report separates the historical load from changes that arrived afterward so the operator can account for both without mixing their clocks.
The first control total is row count by table and migration status. That catches missing batches but says nothing about duplicated identities, broken relationships, or changed amounts. A credible reconciliation adds distinct primary and business identifiers, null counts for required fields, foreign-key coverage, aggregate money or quantity fields, minimum and maximum dates, and application-specific invariants.
Keep exceptions inside the total
Rejected records belong in the reconciliation equation. The report states how many records migrated, how many remain in the rejection queue, how many were intentionally excluded, and whether those groups add back to the fixed source total. Every rejected row gets a reason code and source reference so the buyer can decide whether to correct, waive, or defer it.
Sampling supplements the totals by comparing source and target values for deterministic record selections. Random samples help find broad corruption, while fixed samples around known edge cases make repeated dry runs comparable. The final application smoke tests read through the production code path because a database-level match does not prove that deployed code resolves the new identity or field correctly.
Record the acceptance decision
The buyer sets acceptable differences before execution. A migration that changes a derived timestamp may tolerate a known delta, while an identity mapping may require exact equality. Google Cloud bills backfill and change-data-capture work separately, which is a useful operational distinction as well: the final record should show which source snapshot was loaded and which subsequent changes were applied. The operator closes the backfill only after each threshold has a measured result and named approver.
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: Google Database Migration Service pricing model; AWS migration validation sequence.