CRM Cutover With Reconciliation Exceptions
A customer-data migration must move 4.2 million records from a legacy CRM to a new platform during a six-hour cutover window. Rollback takes 45 minutes and has been rehearsed twice. The final reconciliation shows 1,240 records missing a customer-segment value, 312 duplicate customer IDs, 87 balance mismatches totaling $18,400, and 0.6% of addresses truncated at 40 characters. The new platform enforces a unique ID constraint at write time. The business sponsor says the segment field is 'nice to have' and wants to launch Monday because a marketing campaign is booked. The migration team has one eight-hour reconciliation slot before cutover, and the vendor's support contract covers only the first 72 hours after go-live. Customer service has no procedure for correcting a duplicate ID, and the finance team has not signed off on the balance differences.
1. Make a go/no-go recommendation for the cutover. Which reconciliation exceptions are blocking and which can be accepted with a control?
Read the worked answer
Recommend no-go until the duplicate IDs and balance mismatches are resolved or explicitly accepted by their owners; the segment and address issues can be handled with controls if the business confirms they are not used for entitlements or financial reporting. Duplicate IDs are blocking because the new platform enforces a unique constraint: writes for 312 customers will fail or merge unpredictably, and customer service has no correction procedure. The 87 balance mismatches totaling $18,400 are blocking until finance signs off; a financial difference cannot be waived by the migration team. The 1,240 missing segment values are not automatically blocking if segment is used for marketing and a default plus remediation queue is approved; they become blocking if segment drives pricing, access, or campaign eligibility. The 0.6% address truncation is about 25,000 records; accept only with a customer-service script and a remediation plan if mail or delivery depends on the full address. The decision should be recorded as a conditional go/no-go with named owners, not as a general 'launch anyway.'
2. Design the pre-cutover reconciliation slot and post-go-live monitoring plan.
Read the worked answer
Use the eight-hour slot for a full dry run, not a partial check: freeze source changes, extract a fresh copy, load into the target, and compare row counts, hash totals, key uniqueness, financial sums, and exception reports. Produce an exception register with owner, severity, and proposed disposition. Require finance sign-off on balances and a data-owner sign-off on duplicates before cutover. During cutover, run the same reconciliation in stages so a failure stops before the window is consumed. Post-go-live, monitor duplicate-ID write failures, balance changes, segment nulls, address truncation, and customer-service tickets daily for at least the vendor's 72-hour support window; define rollback triggers such as unresolved duplicate writes or a finance variance above an agreed threshold.
3. How should the team communicate the residual risk to the sponsor and customer service?
Read the worked answer
Tell the sponsor the facts in business terms: the launch is not blocked by cosmetic data quality; it is blocked by 312 customers who may not be writable and 87 financial differences that finance has not accepted. Give the sponsor a choice between a delayed cutover with clean reconciliation and a conditional cutover with named residual risks, remediation owners, and customer-service workarounds. Customer service needs a script for duplicate IDs, a queue for missing segments, and a contact for balance disputes; finance needs a signed variance acceptance. Do not let 'marketing campaign is booked' become the risk owner. Record the residual risk in the cutover decision log and state what would trigger rollback.