AUDITOR - DATA MIGRATION ASSURANCE

Experience: 4 to 8 years, of which at least 2 on data migration, ETL or data-quality testing.

Engagement: Three audit cycles through to programme go-live, then other assurance work.

THE ROLE

You will help audit a large records migration from several legacy systems into a new platform. You will not move the data. You will check whether the system integrator moved it correctly: that no record was dropped, none was duplicated, no field changed value in transit, no photograph or signature was left behind, and every scanned document still points at the right record.

You will write and run your own queries against source and target, design the samples, collect the evidence, and draft the findings. Your work on the production cut-over feeds the client's go-live decision.

WHAT MAKES THIS JOB HARD

- The source estate is heterogeneous. Several source organisations, several different relational database engines between them, including versions long past vendor support.
- Most defects you find will come from encoding, collation, data type scale and data precision differences between those platforms.
- The scanned-document estate dwarfs the database estate. Most of the work is not row counts.

It is proving that images, forms and signatures moved intact and still link to the right record.

- Images are not only files on disk. Some are held inside database columns as encoded strings, not as separate files.

Ordinary file reconciliation never touches them.

- The acceptance standard for production is zero defects. Sampling alone cannot demonstrate zero. You will have to say clearly, in writing, what your testing proves and what it does not.

- The population is not handed to you. Establishing what should have moved, and getting that baseline agreed, is part of the job rather than a given.

THE THREE CYCLES Cycle 1 : Development / Test Is the migration approach fit to carry into UAT

Cycle 2: UAT Is the migrated data valuable enough to proceed to production?

Cycle 3: Production cut-over. The go/no-go report.





Fieldwork windows follow the approved audit plan.

WHAT YOU WILL DO

- Plan. Draft the document request list. Chase what arrives late, short, or not at all, and log the gap. Draft the sampling plan and defend the sample size in writing.

Cycle 1:

- Dev/Test. Read the migration strategy and the source-to-target mapping, and predict where they will silently drop records: inner joins, filters, truncation, date and character-set conversion, dedupe rules. Check trial-run control totals, checksums and the rejected-record register.

Cycle 2:

- UAT. Audit what actually moved. Count both sides yourself. Run anti-joins in both directions for dropped and orphan rows, group-by-having for duplicates created on a re-run, field-level comparison behind a matching row count, and hash comparison of source and target rows. Test that scanned documents, photographs and signatures migrated and still link to the right record. Track defects to closure and retest.

Cycle 3,

- Production. Verify the final reconciliation, control totals and exception closure.
- Check that every rejected record was fixed, reloaded, or written off with approval. Check data protection in transfer, staging and storage: access control, encryption, logging.
- Review rollback and reprocessing evidence; if no rollback plan exists, that is itself the finding. Confirm the sign-offs exist and carry the names of the people the plan says should have signed. Turnaround is short and fixed to the cut-over window.

Throughout. Every statement traces to a file, a query output or a screenshot, with the date, the source, and the name of whoever handed it over. Nothing goes into a report on the strength of a conversation.

MUST HAVE

1. SQL you can write under pressure,



on more than one engine. Counts by key, aggregate control totals, anti-joins in both directions, group-by-having to find duplicates, field-level comparison across two systems, and hash comparison of rows. You will be tested on this at interview.
2. Two years or more on real data migration, ETL, or data-quality testing. You have seen a migration go wrong and know which control should have caught it.
3. You can read a source-to-target mapping and say where it will lose data, and where it fails to tell you enough to test at all.
4. Experience of rejected-record logs and reprocessing, and how to test that every rejection was resolved rather than quietly dropped.
5. You can defend a sampling choice where the population is large and not fully published, and say plainly what your sample does not prove.
6. Written English good enough for a finding that survives challenge: the observation, the evidence, the risk, the recommendation, in that order.
7. You do audit work, not build work. You keep working papers a stranger could follow, and you have held a finding through review and sign-off rather than signing alone.
8. Cross-platform data problems. Encoding, collation, datatype scale, date and time precision.

GOOD TO HAVE

- Reconciling images and documents, not only rows: files against a manifest, links between a record and its scan.
- Any ETL or data-profiling tool used as a tester, as transferable background.
- Python or shell for handling extracts and manifests.
- Government or e-governance programme experience.
- Exposure to data protection duties: the DPDP Act 2023, tokenisation and data vaults, masking in non-production environments.
- Working knowledge of ISO 27001 or ISO 20000.

QUALIFICATIONS AND CERTIFICATIONS

- Required: a degree in engineering, computer applications, or a numerate discipline.
- Preferred: CISA, ISO 27001 Lead Auditor, DAMA CDMP, or a database or cloud data certification.
- Certificates with no fieldwork behind them do not substitute for point 2 above.

📌 Auditor - DATA Migration Assurance (Noida)
🏢 Allied Boston Consultants India
📍 Noida