Two Prospects' Retention Deadlines Were Swapped During CRM Migration: Restore Both Clocks

Two prospects with swapped retention deadlines need separate clocks restored from source evidence. Do not average the dates or choose the later date by default; do not reset both records to the migration date.

The immediate risk is asymmetric. One prospect could be deleted before its governing decision is complete, while the other could be kept after its valid retention period. UK GDPR Article 5 requires personal data to be accurate and, where needed, kept up to date. It also says identifiable data must not be kept longer than necessary for its processing purpose. UK GDPR Article 5

How do you prove the two deadlines were swapped rather than reset?

Build a paired evidence trail. Start with an export or immutable record from the source CRM, then compare it with the destination record and the migration job's mapping configuration, including transforms, and audit events. A swap is supported when Prospect A carries Prospect B's prior deadline and Prospect B carries Prospect A's prior deadline, while each source record still supports its own original deadline.

A reset needs different evidence: a destination deadline calculated from the migration date, a blank source deadline, a new default replacing it, or a transformation that overwrote both values. Do not call it a swap until the two source-to-destination relationships are traceable.

AWS documents that migration validation compares corresponding source and target rows and reports mismatches. Its guidance also notes that validation can be run separately from migration, which is useful when you need an independent check after a repair. AWS DMS data validation

• Export the source record, including source ID, retention basis, deadline, hold status, and last review.
• Export the destination record and its audit history before changing it.
• Trace the migration mapping, transformation rule, batch identifier, and timestamps for both records.
• Record whether each destination deadline exactly matches the other prospect's source deadline.
• Preserve the comparison in the incident record before making a correction.

Which clock governs each prospect after a migration error?

Each prospect's governing clock comes from that prospect's own retention basis and source evidence. The destination field is evidence of what the new system currently holds. It is not, by itself, proof that the date is right.

Check four things for each person: the source retention basis, the original deadline, any current legal hold or preservation instruction, and any required review before deletion. If a legal hold or unresolved review applies, do not delete the record merely because the observed destination date is overdue.

Article 5 also makes the controller responsible for demonstrating compliance with its processing principles. Keep the source export, comparison ledger, approver, correction timestamp, and post-fix test result with the incident. UK GDPR Article 5

• Use the source deadline only if the source retention basis is still valid.
• Treat a legal hold or preservation instruction as a stop on deletion until the responsible owner clears it.
• Route an overdue record with unclear basis to the privacy or legal owner for a documented decision.
• Do not let Prospect A's hold, review result, or deadline decide Prospect B's treatment.

How do you correct overdue decisions without deleting protected data?

Pause automated deletion for only the affected destination records, or isolate them through an approved exception process. Preserve the original destination values and audit history. Then correct one record at a time after the responsible owner confirms its retention basis and hold status.

If one record is overdue and has no active hold or unresolved review, send it through the approved deletion decision process for that record. If the other is protected, retain it under its own documented instruction. Do not delete both records to make the migration mismatch disappear.

Google Cloud recommends complete, current inventory during migration assessment and recommends testing failure modes in a non-critical environment. Apply that principle here by replaying the paired record scenario in a test environment before changing the migration mapping or releasing the deletion exception. Google Cloud migration-plan validation guidance

• Create a scoped deletion pause or exception for the two destination IDs.
• Capture source and destination evidence before editing either record.
• Obtain a documented decision for each record from the owner responsible for retention and holds.
• Write the corrected deadline, basis, reviewer, decision date, and incident ID to the destination audit trail.
• Run a paired migration test that confirms each source deadline stays attached to its own destination record.
• Remove the scoped pause only after the records and audit trail, including the test result, are reviewed.

What migration test prevents the same deadline swap?

Use a paired fixture that deliberately gives two test prospects different retention deadlines and different hold states. The test should fail if either destination record receives the other record's deadline or an associated retention value.

Test the exact transformation and mapping path used in production. AWS documents that table-mapping rules can specify source data selection and transformations before data is written to the target. Review that path, not only the final destination field. AWS DMS table mapping documentation

Keep validation separate from the repair script when possible. A repair that reads its own output can hide the same mapping defect that caused the incident.

• Give the two fixtures distinct source IDs, deadlines, retention bases, and hold states.
• Assert that every destination field maps to the same subject's source record.
• Run the test before deployment and retain the output with the change request.
• Add a post-migration exception report for deadline values that duplicate across unrelated records.

What should the incident record contain before closure?

Close only when the two clocks are individually supported, the destination audit trail shows the approved correction, and the paired test passes. Keep the incident narrow. The goal is to restore accurate treatment for two people, not rewrite retention rules during a migration repair.

NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk through enterprise risk management. Use the incident record to make the ownership, evidence, decision, and control failure visible to the people who manage that risk. NIST Privacy Framework

• Affected source IDs and destination IDs.
• Source evidence and observed destination values captured before repair.
• Retention basis, hold status, review status, and decision owner for each prospect.
• Approved correction and its timestamped audit reference for each record.
• Migration mapping cause and the paired-test result for the prevention change.