Back to the blog

Recruitment CRM · 6 September 2026

Recruitment CRM data migration: a verification checklist

Check candidate records, vacancy links, open tasks and late changes before switching your staffing team to a new recruitment CRM.

Hands comparing plain work cards between two laptops on an oak office table

Turn insight into action

Need this fixed inside your staffing workflow?

We help staffing teams tighten intake, follow-up, CRM structure, and recruiter handoff without adding a heavy system.

  • Fewer lost candidates
  • Clearer recruiter next steps
  • Better pipeline visibility

A recruitment CRM data migration is ready for use when recruiters can find the right candidate, understand the linked vacancy and continue the correct next action. Matching the total number of imported rows is only one check. You also need to verify relationships, contact restrictions, open tasks and changes made after the original export.

For a staffing agency changing systems, the practical approach is to agree what will move, preserve source references, test a representative sample and reconcile the final import before switching daily work. This checklist focuses on the transfer of working data. The broader CRM implementation guide covers process design and team rollout.

Define the scope in operational terms

Start with a list of record types and the reason each is needed in the new system. Candidates, applications, vacancies, client contacts, notes and follow-up tasks are separate objects even if the old export combines them. Decide which current work must be available at cutover and which historical material needs a different approved destination.

Do not assume every old record should enter a live recruiter queue. Equally, do not exclude history simply because it is inconvenient to map. Ask the responsible data owner to confirm what the agency needs and may transfer. This is a scoping decision for your organisation, not a universal retention rule.

Record exclusions explicitly. A reconciliation cannot explain missing records if nobody documented which records were deliberately left out. Keep a protected copy of the agreed source export for comparison during the migration, following your agency's handling arrangements.

Map meaning, not just column names

Create a mapping sheet with the source field, destination field, transformation rule and reviewer. Add a plain-language description of what the value means. “Available” might mean available for contact in one system and ready to start work in another. Moving the word without its meaning changes recruiter decisions.

Check dates, phone numbers, language preferences and owner assignments carefully. Preserve international phone prefixes and confirm how date-only values differ from appointment times. Test accented names and place names. A Polish surname or a Spanish location should remain searchable after import.

For ambiguous values, use a review state rather than silently selecting a convenient default. Refer to the mandatory CRM fields guide when deciding which missing details block live work. Migration should not manufacture information that the source never contained.

Preserve relationships and source references

A candidate can have several applications, and a vacancy can have several candidates. Exporting a flat list may obscure these relationships. Agree how the new system will connect candidate, application, vacancy and task records, and preserve the old identifiers or a reliable cross-reference.

Do not merge people solely because their names match. Shared contact details also deserve review rather than an automatic assumption. Separate an intentional merge from an import failure, and keep a record of which source profiles became one destination profile.

Microsoft's configuration migration documentation explicitly treats relationships and uniqueness as migration concerns. Its tool concerns configuration data; it is not a candidate migration prescription or evidence of an AI JOB AGENCY integration. Use your actual supplier's documentation to establish supported import behaviour.

Test a sample that reflects the desk

Choose test cases for their operational differences, not because they are easy to import. Include a candidate linked to two vacancies, an open callback, a changed appointment, a closed application, a record with missing information and a profile with a contact restriction. Use synthetic records where possible for initial mapping checks.

For each case, ask a recruiter to perform the next real action in the destination system without sending live messages. Can they see the correct vacancy? Does the note belong to the right interaction? Does the task retain its owner and due time? Does a closed application stay out of the active queue?

Keep outbound automation disabled for the test import. Imported history must not unexpectedly trigger candidate messages. Ask the implementer how imports interact with workflow rules before using production records, because supported controls vary between systems.

Reconcile totals and explain differences

Compare counts by record type, branch and operational status. A single overall total can hide candidates moved into the wrong branch or open applications imported as closed. Then compare source identifiers to destination identifiers so missing and repeated records can be investigated individually.

For an illustrative batch of 100 source profiles, the agreed outcome could be 94 imported separately, four intentionally excluded and two deliberately merged into existing records. The numbers are a worked example, not a benchmark. The important result is that every source record has an explained outcome.

Also inspect relationships and critical fields across the sample. Matching counts will not detect a callback linked to the wrong vacancy. Keep discrepancies in one list with an owner, proposed correction and verification result. Do not approve unexplained differences simply because most rows loaded successfully.

Plan the final export and the first working morning

Agree a clear cutover time and where new information will be recorded during the transfer. If the old system remains editable, establish how changes after the export will be captured and applied. Avoid asking recruiters to improvise between two systems with no authoritative record.

Consider a hypothetical agency with a Dutch branch and a Polish recruitment desk. A candidate changes availability after the trial export. The final migration must carry that newer answer into the destination without duplicating the earlier profile. The reviewer checks the source reference and last confirmed update before releasing the record to the recruiter.

Name the person who can approve cutover and the conditions that delay it. Missing live tasks, lost contact restrictions or broken vacancy links deserve resolution before affected work moves. Define a rollback procedure with your implementer, including how work created after cutover would be preserved if the team must return temporarily.

Practical checklist and common mistakes

Common mistakes include measuring success only by row count, switching on messages during a test import and letting every branch interpret a field differently. Another is approving the trial run without checking updates made between trial and final migration.

  • Agree included records and document exclusions.
  • Review field meaning and transformation rules.
  • Preserve source identifiers and application relationships.
  • Test real recruiter actions without live sends.
  • Explain count differences and inspect critical values.
  • Reconcile late changes and obtain named cutover approval.

FAQ

Should we migrate the whole candidate database?

Decide scope with the data owner and operational lead. Transfer what is justified for the new workflow and agreed historical needs. Document exclusions and their destination rather than treating migration as an unreviewed bulk copy.

Are matching record counts sufficient?

No. Counts show volume, not correct relationships or meaning. Check identifiers, statuses, owners and representative linked records as well as totals.

Can old and new systems run together?

Only with explicit rules about where updates are authoritative and how changes are reconciled. Otherwise two teams may change the same candidate independently and neither record remains dependable.

Who should sign off the migration?

A named operational owner should approve the business result with technical and data-owner input. Recruiters should demonstrate that they can continue actual work in the new system.

When can automated follow-up resume?

After validating the affected records and checking which imported events can trigger messages or tasks. Resume within the verified scope and inspect the first results before expanding.

For a migration discussion, bring an anonymised field list and examples of the relationships your team must preserve. Contact AI JOB AGENCY to discuss scope alongside the recruitment CRM workflow.

Turn insight into action

Need this fixed inside your staffing workflow?

We help staffing teams tighten intake, follow-up, CRM structure, and recruiter handoff without adding a heavy system.

  • Fewer lost candidates
  • Clearer recruiter next steps
  • Better pipeline visibility