Data Migration Audit: Controls and Checklist
Whatever goes wrong in migration becomes the new system's opening position.
Data migration (the background material calls it data conversion) is moving data from an old system into a new one: masters, open items and balances from a legacy accounting package into an ERP, or account records from one core banking platform to another. It happens once, under deadline pressure, usually with elevated access, and whatever goes wrong becomes the new system's opening position.
ICAI's Module 3 treats conversion as a form of input, so it needs input-style controls over completeness and accuracy. It also says plainly that unauthorised changes during conversion are one source of fraud. Both points shape the audit.
You save ₹450
- Full-length timed mocks
- Module-wise practice
- Emerging-tech coverage
One payment, no subscription · Valid for 2 months
Three Kinds of Conversion
- Data conversion
- Moving data into the new system: capture, verify and upload when replacing a manual process; convert format, verify and upload when replacing an older system.
- Procedure conversion
- Rewriting operating procedures and their controls for the new system, and training the people who will follow them, before conversion starts.
- System conversion
- Shifting daily processing to the new system once converted files are confirmed reliable; the old system may be kept running for a while to compare totals.
Completeness and Accuracy Controls
Record counts
What it proves
Every record left the old system and arrived in the new one
Example
Number of vendor masters and open purchase orders before and after
Control and batch totals
What it proves
Monetary values carried across intact
Example
Total receivables and payables by ledger before and after
Hash totals
What it proves
No record was altered or swapped, even where amounts still agree
Example
Sum of numeric vendor or customer codes before and after
Trial balance comparison
What it proves
The books still balance at the same figures
Example
Closing trial balance in the old package equals opening trial balance in the new
Manual or key verification
What it proves
Field-level accuracy where data is re-keyed
Example
Sample of migrated masters checked against source documents
| Control | What it proves | Example |
|---|---|---|
| Record counts | Every record left the old system and arrived in the new one | Number of vendor masters and open purchase orders before and after |
| Control and batch totals | Monetary values carried across intact | Total receivables and payables by ledger before and after |
| Hash totals | No record was altered or swapped, even where amounts still agree | Sum of numeric vendor or customer codes before and after |
| Trial balance comparison | The books still balance at the same figures | Closing trial balance in the old package equals opening trial balance in the new |
| Manual or key verification | Field-level accuracy where data is re-keyed | Sample of migrated masters checked against source documents |
An Example: Legacy Package to ERP
A mid-size manufacturer moves from a desktop accounting package to an ERP at the start of a financial year. Migration covers the chart of accounts, vendor and customer masters with GSTINs and bank details, item masters with HSN codes, open purchase and sales orders, inventory by location and batch, and opening balances by ledger.
The risks are specific. Vendor bank details changed during migration create a payment fraud route that no later input control will catch, because the new system treats the data as already approved. Cleansing decisions such as merging duplicate vendors or writing off old balances are accounting judgements, not IT tasks, and need owner approval. And an open-items migration that agrees in total can still misallocate amounts between parties.
Quick practice on audit concepts. No signup.
What to Check in a Migration Audit
- checkAn approved migration plan and a field mapping from old to new, with transformation rules
- checkCleansing and write-off decisions approved by the data owner, with the list retained
- checkTrial migrations run and reconciled before the final one
- checkAccess to migration tools and staging data restricted, logged and removed after go-live
- checkRecord counts, control totals and hash totals reconciled for each data object
- checkReconciliations reviewed and signed off by user departments before go-live, as Module 3 requires before final sign-off
- checkLegacy data retained in read-only form for comparison and future audit
- checkException reports on masters changed between extraction and go-live
How the Changeover Strategy Affects Migration
Module 3's four implementation strategies each put different pressure on conversion:
| Strategy | Effect on migration |
|---|---|
| Cut-off (direct) | One conversion on a set date; rollback is hardest, so conversion must be planned and rehearsed well in advance |
| Phased | Converts one function at a time; interfaces between old and new carry data in the meantime |
| Pilot | Converts one site or branch first; lessons feed the later conversions |
| Parallel | Both systems run and outputs are compared; the safest route, but every transaction is processed twice |
How the DISA Assessment Test Tests This
- check_circleBest evidence of completeness: record counts and control totals reconciled, not a user's statement that the data looks right
- check_circleWho confirms conversion: the user department or data owner signs off, not the IT team that ran it
- check_circleMost secure changeover: parallel; highest rollback risk: cut-off
- check_circleThe trap: the auditor performing the reconciliation. The auditor reviews it; management owns it
FAQs
What controls ensure completeness in data migration?expand_more
Record counts, control totals, batch totals and hash totals compared before and after conversion, and a trial balance comparison for financial data. ICAI's Module 3 lists these as completeness checks for conversion.
Who should sign off on data conversion?expand_more
The user departments that own the data. Module 3 asks the auditor to verify that conversion was confirmed by them before the system went live and final sign-off was given.
Why is data migration a fraud risk?expand_more
Data loaded during migration enters without the normal input controls and with elevated access. A changed bank account or inflated balance becomes trusted data in the new system.
What is the difference between data conversion and system conversion?expand_more
Data conversion moves and verifies the data. System conversion is the point where daily processing switches to the new system after the converted data is confirmed.
Next steps
- ERP Auditarrow_forward
- Application Controlsarrow_forward
- Post-Implementation Reviewarrow_forward
- SDLC Phasesarrow_forward
Assessment Test format, timed and scored.