Candidate Data Quality Gate Before ATS Migration (Onboarding)

Candidate Data Quality Gate Before ATS Migration (Onboarding)

1. 01

   Freeze the source system and export a full candidate dataset, not a filtered view

   Pull every record including rejected, withdrawn, and duplicate entries. A filtered export hides the duplicates and orphaned records that surface as broken pipelines after cutover.

2. 02

   Score field completeness against the destination schema before writing any mapping

   Flag records missing email, phone, current employer, or consent status. In small-business hiring stacks such as JazzHR, a missing consent field can block an entire offer workflow downstream.

3. 03

   Deduplicate on email plus name-plus-employer pairs, then resolve conflicts by most recent activity

   Merge rules should be written down and signed off by the client contact. Recruiting agency workspaces like Harbor often hold the same candidate across multiple job orders, so naive deduplication destroys placement history.

4. 04

   Map pipeline stages one-to-one and document every stage that has no destination equivalent

   Stage names rarely translate cleanly between systems. Where a stage has no match, decide whether it collapses into an adjacent stage or becomes a custom status before migration begins.

5. 05

   Reconcile client and job-order records separately from candidate records

   Recruiting CRM platforms such as Top Echelon tie candidates to clients and placements in one workspace. Migrating candidates without their client and job-order links leaves recruiters with a list of names and no context.

6. 06

   Run a 50-record pilot load and diff the output against the source export

   Compare field-by-field on a sample that includes at least five edge cases: a duplicate, a withdrawn candidate, a record with no email, a multi-stage history, and a candidate tied to two clients.

7. 07

   Archive the pre-migration export with a dated checksum and hand the client a rollback path

   Keep the archive for at least the length of the retainer plus 90 days. If the migration is later disputed, the checksum proves what the source data looked like on cutover day.