<link href="https://fonts.googleapis.com/css2?family=Figtree:wght@300;400;500;600;700;800;900&amp;display=swap" rel="stylesheet"> NewsHR Systems joins Skillcloud HCM Solutions, expanding HR, payroll and workforce supportRead the announcement
Managed Services & Consulting for HR · Payroll · HRIS · Talent
HR Technology

Switching ATS: what happens to your candidate history

The question that gets asked late — often after a contract is signed — is what happens to everything already in the old system.

HR Technology6 min read

What's in this article

  1. Why candidate history is hard to move
  2. What a complete migration covers
  3. Questions worth asking before you migrate

When an organization changes applicant tracking systems, the conversation is usually about features, workflow and price. The question that gets asked late — often after a contract is signed — is what happens to everything already in the old system.

That history matters more than it seems. Past applicants are a sourcing pool. Disposition records support defensible hiring decisions. Applications and resumes are records you may be obligated to retain. A migration that moves only active requisitions leaves all of it behind.

Why candidate history is hard to move

The difficulty is structural rather than technical. In the legacy system, a candidate is attached to a requisition. In the new system, that requisition does not exist — so there is nothing for the candidate record to attach to.

The shortcut that causes the damage

The common workaround is to load historical candidates into a single generic bucket — one catch-all requisition holding everyone who ever applied. The records technically exist, but the connection between a candidate and the role they applied for is gone, and that connection is most of the value.

Doing it properly means rebuilding the legacy requisitions in the new system first, so each historical candidate has the job they actually applied for to attach to.

What a complete migration covers

Phase 1
Access & rebuild
Secure access to both systems; legacy requisitions rebuilt in the new ATS.
Phase 2
Extract & organize
Candidate data and documents extracted and organized by candidate.
Phase 3
Audit & migrate
Extraction validated against the source, then migrated to the correct job.
Phase 4
Validate & close
Upload audited in the destination, then documented handoff.

The work includes candidate and applicant data, their documents — resumes, applications, supporting files — and disposition and status detail carried across where the destination system supports it. Each candidate lands on the job they actually applied for, with their documents attached.

That last clause carries a caveat worth understanding: destination systems differ in what they will accept. Some preserve full disposition detail; others support a narrower set of statuses. Establishing what the new system can hold, before extraction begins, prevents discovering the limit halfway through.

Questions worth asking before you migrate

  • Are historical requisitions being rebuilt, or is everything going into one bucket? This is the question that separates a real migration from a data dump.
  • Are documents moving, or only structured data? Resumes and applications are often the part quietly dropped, because they are the harder half.
  • Is the extraction validated against the source? Counting records out and counting them in is not the same as verifying they arrived intact.
  • What does the destination support? Disposition detail, custom fields and status history vary by platform.
  • What are your retention obligations? Application records carry retention requirements, and those do not pause because you changed systems.

ATS migration is priced per candidate, because the work scales with the number of applicant records rather than the size of the company — which also means the cost is known before the project starts.

The short version
  • Candidate history is a sourcing pool, a defensibility record and a retention obligation — not archive material.
  • The structural problem: candidates attach to requisitions, and those requisitions do not exist in the new system.
  • Loading everyone into one generic bucket preserves the records and destroys the context.
  • Establish what the destination system can hold before extraction starts.

Common questions

You can move structured data that way, but it leaves behind the documents and the relationship between a candidate and the requisition they applied to. A spreadsheet of names is not applicant history.
Those requisitions get rebuilt in the new system so the candidates have somewhere accurate to land. Without that step, historical candidates end up in a generic bucket with no connection to what they applied for.
They should. Documents are extracted, organized by candidate, and attached to the candidate record in the destination. Document handling is the harder half of the work and the part most often left out of a migration scope.
Per candidate, because the work scales with the number of applicant records rather than headcount. That also means the cost is known before the project begins.

Changing ATS this year?

Tell us what you are moving from and to, and roughly how many applicant records are involved.

Talk to an Advisor
Related

Keep reading

Service

ATS Migration

Applicant history moved to the job each candidate actually applied for.

Service

Document Transfer

Employee documents extracted, organized and loaded into the new system.

Service

Talent Solutions

Recruiting coordination, hiring surges and talent operations.

Let's Talk

Have a question this article did not answer?

Every system and every migration is different. Tell us what you are working with and we will give you a straight answer.

Talk to an Advisor