Data Conversion and Migration

Data conversion and migration. This is the sharpest risk in the domain, and the exam tests one control above all others: reconciling the data from the old system to the new one.

The situation. The new system goes live on Monday. Over the weekend, three years of customer and transaction data will move across from the old one. The project plan treats the conversion as a single line item, and the step right after it, on the same weekend, is to switch the old system off to save on running costs. Everything now rests on one overnight event that, if it goes wrong quietly, no one may notice until it is too late.

What makes conversion so sharp is this: most controls operate continuously and get many chances to catch a problem. Data conversion gets one. The data moves once, and if records are lost, duplicated or corrupted in the move, the new system starts its life on wrong data, and every process built on it inherits the error.

So it is controlled as the high-risk event it is. First, cleanse the data first: fix duplicates, errors and obsolete records in the old system before conversion, not after. Garbage converted is still garbage.

Second, map the fields: every field in the source must map to the right field in the target, with values translated correctly where the formats differ.

And third, convert, then validate. The move is followed by checking, never assumed to have worked. Which brings us to how you check it.

The control that proves a conversion is reconciliation of source to target, and it answers two questions with evidence. Completeness: compare record counts, source against target, did every record arrive. A mismatch means records were lost or duplicated. Accuracy: compare control totals, the sum of a numeric field such as account balances, across source and target. Equal totals give strong evidence the values were not altered in the move.

Now apply the Domain 1 evidence hierarchy. The project’s migration successful report is self-reported by the people who ran it, the weakest position. The migration tool’s log shows the job finished, not that it finished correctly, a run can complete and still silently drop rows. The strongest evidence is the reconciliation the auditor performs or independently re-checks. Verify it yourself; do not accept that it was verified.

The sequence matters too. Convert, reconcile, validate, get business sign-off, and only then plan to decommission the source, with the old data retained for a defined period. What you do not do is switch the old system off over the same weekend to save cost, trusting the completion report, because that loses your only fallback and your reconciliation reference at once.

And that is the reason: do not switch off the fallback. The old system is both the reference you reconcile against and the way to keep operating if the new one fails. Conversion errors often surface a week later, and when they do, the source is what you compare against to find them, and reverting to it is how you keep running while you fix them. Retire it too early and you lose both.

This whole lesson is a Domain 1 echo. The team that ran the migration is the party whose work is in question, so their assurance is the weakest kind of evidence. The reconciliation you verify yourself, counts and totals, outranks any report they hand you.

So carry this away. Conversion is a one-time event; control it like one. Prove it with counts and totals you check yourself, and keep the old data until the new system has earned your trust.