Cutover With a Reconciliation Gap

No-go on the announced date as it stands, but the decision is per-category, not on the 1,146 total.

Category by category:

1. 38 duplicates - blocker, but a small and well-understood one. The count is wrong at the identity layer. Duplicated customers mean duplicated communications, split order history, and incorrect entitlement. Because the cause (loader retry) is known and the population is 38, this is a few hours of work: fix idempotency in the loader, re-run, re-reconcile. A blocker that is cheap to clear is not a reason to delay a week; it is a reason to clear it today.
2. 71 null timestamps - needs classification before a verdict. Are they null in the source too, or were they lost in transit? If null at source, they are faithfully migrated and not a defect. If lost in transit, the same reasoning as any audit field applies: do not invent a value. This category cannot be judged until it is split.
3. ~1,100 derived lifetime-value mismatches - the real risk, and the one to scrutinise. A derived field disagreeing by >1% suggests the derivation logic differs between systems, not that data was lost. If downstream teams use this field for credit limits, pricing, or segmentation, a 1% drift is a business error with a slow fuse. It requires a sample of 30-50 records traced end to end before anyone can say whether the target is wrong or the source was.

Decision rule: go only when every category is either cleared or formally accepted with a named owner and a written rationale. Today, category 1 is clearable, category 2 is undiagnosed, category 3 is undiagnosed and carries business consequence. That is a no-go for the date as announced.

Do not sign a clean sign-off. Sign a scoped one that states exactly what you are accepting and what remains open - or decline, if the sponsor will not take that.

Frame the cost comparison honestly:

• Delay costs $60,000 per day. If the fixes take two working days, the delay is roughly $120,000.
• Duplicated customer records in a live system are not a $120,000 problem. Duplicate billing, duplicate fulfilment, split order history, and reconciliation effort to unwind them after the fact typically cost more than the delay - and the cost lands on operations, not on the project budget, which is why the sponsor does not see it.
• The lifetime-value drift has an unquantified but asymmetric downside: if it feeds credit or pricing decisions, the error compounds daily after cutover.

What to offer instead of a bare yes or no:

1. A narrowed scope. Hold back the ~1,100 lifetime-value records from cutover, migrate the remaining high-confidence population, and process the exceptions in a controlled queue after go-live. This protects the date for the 99.9% and isolates the uncertain 0.05%.
2. Duplicates cleared before cutover, unconditionally - hours of work, removes the identity-layer risk entirely.
3. Timestamps split and dispositioned in writing before any sign-off.
4. A written exception register signed by the sponsor, naming the open categories, the owner, and the date by which each closes.

What not to do: accept verbal assurance and proceed. The partner announcement is a communications problem; it will be handled with one message either way, and it is not a reason to carry unquantified data defects into production. If the sponsor insists on a clean sign-off with category 3 unresolved, escalate - that is a risk-acceptance decision above your authority, and it should be documented as such.

A three-day rollback window reduces the cost of being wrong, but it must not be used as a reason to go early.

What rollback genuinely buys you:

• It converts some unknown-severity defects from 'permanent' to 'recoverable within 72 hours.' That is a real risk reduction for transient failure modes - load problems, integration breakage, missing grants.
• It does not help with defects that write bad data downstream in the first day. If lifetime-value drift feeds a pricing run or duplicate records trigger outbound communications, the damage escapes the migration system and rollback cannot recall it. This is the crucial distinction: rollback undoes the migration, not the consequences.

Therefore the posture is: rollback lowers the barrier for functionally verified data with operational uncertainty, and raises no comfort at all for unverified data with downstream consumers.

Pre-agreed triggers to roll back - decided now, not in the incident:

1. Any duplicate detected in live customer identity, or any outbound communication reaching a duplicated record.
2. Lifetime-value mismatches exceeding the pre-cutover rate on the live population.
3. Any downstream consumer reading the drifted field in a batch run before the exception queue is cleared.

The discipline that matters: write the triggers and the decision owner down before cutover. The value of a 72-hour window collapses if the decision to use it takes 48 hours to reach, which is exactly the failure mode this project has already shown with its reconciliation gaps.