Handle Data Migration Quality Concerns Before a Launch Decision

Duplicate records during a test migration deserve a focused quality review before anyone frames a launch recommendation. A delivery director keeps discussion anchored in evidence, correction work, business acceptance, and sponsor choice. Those subjects often blur together during a tense call. Separating them gives every participant a useful job and prevents a technical explanation from becoming an unsupported release decision.

Begin with a narrow statement of the observed result. Name the migration run, affected record population, method used for finding duplicates, and count under review. “Run four produced 38 duplicate active customer records in test output” offers more value than “data quality looks poor.” Add report location, report owner, and time of extraction. Reviewers then start from one shared result rather than competing descriptions from separate meetings.

Gather source extracts, approved mapping version, transformation settings, reconciliation output, defect record, and any source change notes in one review folder. Date each item and name its owner. A source field definition from an earlier workshop might differ from a definition used during a later cleanup effort. Side by side material helps reviewers locate such changes without relying on memory. Keep informal discussion notes separate from evidence.

Ask a named data governance lead which quality conditions govern readiness. Do not assume a technical rerun with fewer exceptions equals business acceptance. A steward might judge duplicate active customer records unacceptable because staff need one view for each customer. Another result might need a different review. Record acceptance language in terms business users recognize, such as “No duplicate active customer records appear in reconciliation output.”

Separate four questions during review. What did testing show. What condition produced the result. Who owns correction work. Who decides whether evidence supports launch. One person might answer several questions, yet each answer belongs in a different record. An integration lead explains matching logic. A data steward judges business meaning. A sponsor decides timing within project governance. This separation keeps responsibility visible during status pressure.

Create an exception sheet for each duplicate group. Include group identifier, source key, target key, record type, suspected cause, correction owner, planned correction, validation method, and review date. Replace “under investigation” after first review with a usable next step. “Integration lead reviews matching rule and supplies comparison output Tuesday at 2 p.m.” leaves a traceable path. Unknown cause is acceptable when investigation ownership and evidence date are clear.

Ask whether duplicates began in source material or appeared after transformation. A source duplicate needs steward review before another extract. A target duplicate tied to matching logic needs rule correction and rerun evidence. A mismatch between test script and target result needs test lead review. These paths call for different work. Naming the path prevents a team from removing one symptom while another condition stays unexamined.

Use a decision record beside the defect record. The defect record holds evidence and correction activity. The decision record names decision owner, needed date, options, and required material. For a Friday release review, write “Sponsor decision Thursday at 4 p.m. Required material includes rerun reconciliation, steward acceptance entry, and open exception count.” Avoid a status line claiming release timing is safe before those materials exist.

Before rerun, record proposed rule version, source extract date, target environment, and test population. Keep those inputs stable until reconciliation finishes. Otherwise, reviewers might compare results from different conditions and reach a false conclusion. Attach a short run note identifying who started output, who checked completion, and where results were stored. This small record makes later comparison faster and gives a steward confidence in review sequence.

In a fictional project review, chief data officer Priya asks, “Do we still launch Friday? Why did your team miss this?” Delivery director Owen replies, “Run four shows 38 duplicate active customer records. A source team note from Tuesday describes a field definition change after mapping approval. Steward review of corrected mapping and rerun evidence must happen before a readiness recommendation.” Priya says leadership expects an answer before Thursday.

Owen does not debate fault or offer a date prediction. He opens the decision record and says, “One path reaches sponsor review if rerun output shows no active customer duplicates and Dana records business acceptance by Thursday noon. Another path needs a revised date or changed scope. Sponsor review selects between those paths after evidence review.” Priya asks who supplies material. Owen assigns rerun output to the integration lead, sample validation to Dana, and packet assembly to himself.

Dana requests ten sample records from every duplicate group. Each sample needs original source values, matching rule, transformed target values, and expected business result. The integration lead agrees to provide material Wednesday morning. Owen books a thirty minute evidence review for Wednesday afternoon. No participant claims resolution before review. Every request has an owner, date, and reason.

Prepare samples so a steward sees business meaning without deciphering a dense technical extract. Include ordinary records and records from each observed exception pattern. Label fields in familiar terms. Follow project procedures for restricted values when broad sharing would be inappropriate. A sample is not proof by itself. Pair sample review with reconciliation output showing population count and duplicate count from the rerun.

At evidence review, start with result. State how many records entered rerun, how many duplicates appeared, which groups cleared, and which groups still need work. If no duplicates appear, ask Dana whether reconciliation and sample review meet her acceptance condition. If an exception persists, record effect, correction owner, next evidence date, and sponsor decision needed. Do not hide an open group under a long account of technical effort.

Send separate updates for leadership and working reviewers. Leaders need decision date, evidence status, open count, and choice requiring direction. Stewards and delivery staff need record locations, sample status, and correction detail. One message full of raw logs serves neither audience well. Use stable labels across updates so a group identifier means the same thing in every discussion.

Use a fictional practice situation before a live review. Write an exception sheet for 24 duplicate supplier records found during a Wednesday test run. Assign source identifier review to Morgan, matching rule correction to Inez, and sample acceptance to Ravi. Set evidence review for Thursday at 11 a.m. Ask a colleague to play a sponsor seeking a Monday release answer.

Answer with the evidence path. State which rerun result exists, which validation remains, and whose acceptance entry is due. Then open the exception sheet, add the sponsor deadline, and assign Morgan the first source sample before everyone leaves the practice meeting.