Project: review Harbor’s order-status backfill

Last updated: 7 Oct 202618 min read

project

Review a fictional Harbor Orders migration from legacy status text to a typed status field. The model drafts mapping and validation plans. The migration runner and authorized operator control writes. Count parity alone does not establish value equivalence, tail completion, or safe cutover.

Review the packet

Snapshot H-47 contains 47,000 orders. The approved mapping handles 46,940; 60 are quarantined, comprising 47 unknown legacy statuses and 13 rows missing a tenant ID. The destination holds 46,940 rows after backfill, but three fail a field-level comparison. Thus 46,937 mapped rows currently match. Harbor holds cutover, assigns the 60 exceptions and three mismatches, and plans a fresh validation after repair. Writes continue in the legacy table; change-tail position and lag must also be verified before any switch.

Source snapshot 47,000 = mapped 46,940 + quarantined 60
Quarantine: 47 unknown status + 13 tenant ID missing
Destination 46,940 = matching 46,937 + mismatched 3
Current write owner: legacy table
Decision: hold cutover; resolve exceptions and tail

Performance and review cost

Scanning N source rows and writing eligible rows is O(N) application work, with database I/O and index maintenance often dominating. Field comparison adds another O(N) pass, and live-tail replay depends on concurrent write volume. Keep row-level exception IDs and a watermark so retries remain bounded and failed cutovers can be investigated without reconstructing the whole run.

Common Mistakes

Do not call 46,940 destination rows 46,940 validated matches.
Do not map unknown statuses to a convenient default.
Do not cut over while value mismatches, exceptions, and tail evidence remain unresolved.

Related lessons

prompt engineering

database migration