You switch ATS without losing candidates by migrating in phases: audit your data, export it, map the fields, run both systems in parallel, then cut over and verify. Handled in that order, even a live pipeline moves across intact, so there is no reason to stay on an ageing ATS just because switching feels risky.

For most teams, it is plain fear that keeps them on an old ATS. Moving a live pipeline and its integrations at once feels risky, and a single botched export can drop people mid-process. The risk is real, but you can handle it: switch-ready platforms, Sprad among them, plug into the stack you already run, so you land on a system that already talks to your HR software and job boards from day one.

The gap between a clean switch and a lost pipeline comes down to a handful of decisions:

What are the steps to migrate to a new ATS?

Migrating to a new ATS runs through six phases, and keeping them in order is what protects your candidates. The timeline spans a wide range: a self-serve platform can be live in a few hours, while a large enterprise with heavy integrations can take two to four months. Company size and integration count drive that range, so the phases below matter more than the calendar.

Choosing where to move is its own decision, and it pays to compare the landscape first. Our map of the vendor categories shows what each type of tool actually automates. With the destination set, the six phases above turn the switch into routine project work, and the parallel run is the phase that keeps candidates safest: detailed migration guides recommend running both systems for one to four weeks before a weekend cutover.

Which candidate data must you migrate, and what should you leave behind?

Migrate everything that keeps a candidate in play or proves how you handled them, and leave behind everything that only adds clutter or legal risk. A clean migration is mostly a data-hygiene job done up front, so classify your records before you move a single one. Most organizations migrate only the last one to two years of activity and archive older records offline, which keeps the new system fast and the data defensible.

The original file matters more than teams expect. Only the file itself counts as the legally required record, so an original CV or offer letter has to move across as an actual file, because parsed text fields do not satisfy the record-keeping rule. GDPR reinforces this from the candidate side, since the right to data portability means personal data must be exportable in a structured, machine-readable format, with a one-month window to respond.

Before you export, clean up under GDPR: process any pending right-to-erasure requests in the old system, exclude candidates who have withdrawn consent, and carry consent timestamps across. In the DACH region, rejected-applicant records are generally deleted after about six months, so migrating recent data only is usually the compliant default.

Documenting all of this now pays off twice, because the same records prove your GDPR and EU AI Act duties and travel cleanly into the new system. Sloppy consent data in the old ATS becomes sloppy consent data in the new one.

Where do ATS migrations actually lose candidates?

The biggest risk is treating candidate data like a spreadsheet. A detailed ATS migration checklist shows why: candidate records are relational, so flattening them to CSV quietly duplicates people and strips the stage-history timestamps that tell you where each candidate stands. Treat the move as a data-model translation, where each candidate stays linked to their applications in the new structure.

Attachments are the most fragile part of the whole move. Most ATS APIs hand back temporary signed URLs for each CV and letter, which is why a careless export can lose the one file you are legally required to keep.

Common mistake: exporting attachment links and downloading the files later. Those links often expire within a day, so the deferred download returns dead links. Capture every file in the same run as the export, and check a sample opens before you move on.

Some lost candidates never had a data problem at all. If the switch breaks your application form or interrupts your candidate emails, people quietly drop out, and the numbers are hard to ignore. In largely North American data, around 60% abandon applications that feel long or complex, and requiring account creation lifts abandonment by roughly 40%. A stalled process also feeds ghosting, the top job-search frustration for 59% of candidates, so protecting the candidate experience through the switch is as important as protecting the database.

Export lock-in, broken integrations and team buy-in: the switch risks beyond your data

Getting your data out is sometimes the hardest step, because some vendors make leaving slow and expensive. Export can mean raising a support ticket and waiting five to ten business days, with certain reports billed separately on top. The fix is to test your exit before you sign anywhere new.

Test your exit before you sign: ask the new vendor to export a sample of your data and confirm it is usable, including history and object relationships. Get in writing what you can export, and in what format and timeframe. If a vendor makes it easy to walk away later, that is a good sign it is safe to commit to now.

Integrations tend to break quietly. The usual culprits are expired OAuth tokens and deprecated API versions, and the damage stays invisible because a hired candidate can stop syncing to payroll for weeks before anyone notices. The scale is well documented: 81% of HR professionals say weak integration holds back their goals, while only 39% consider their systems usefully connected. Re-test every connection right after cutover, before you rely on it.

Even a flawless data move fails if the team quietly refuses to adopt the new tool. Recruiters slide back to spreadsheets and email when a system feels like extra work, which is why migrations succeed or stall on people more than technology. A named executive sponsor changes the odds sharply: projects without one fail at about three times the rate. Pair that sponsor with role-based training and a written project plan, and adoption stops being the thing that undoes an otherwise clean switch.

How an ATS that fits your stack cuts the cost of switching

Only about 28% of companies are happy with their current ATS, and one in four plan to replace it within the year, so if you want out, you are in good company. What decides the cost of that switch is how well the destination already fits the tools around it. When the new ATS speaks to your existing stack on day one, the integration re-wiring everyone dreads mostly disappears.

Modern OAuth-marketplace integrations have already cut that re-wiring from months to minutes, though custom fields and stages still need a few hours of mapping. That is exactly where Sprad sits. It plugs into the HR system you already run, whether that is Personio or Workday, and keeps posting to LinkedIn and Indeed, so hires still flow back into payroll without a rebuild. Because you connect it to your stack while keeping the systems around it, the switch stays low-risk from the first day.

The rest of the switching cost comes down to time and commitment, and both stay low here. Sprad goes live in under ten minutes, and its free core lets you trial the full recruiting workflow, from career page to pipeline, before you commit a single record. Hosting sits in the EU with GDPR and EU AI Act compliance built in, which matters when you are moving candidate data across systems. If you are still scoping the market, it is worth browsing the applicant-management category to see where a free, AI-native option fits.

Turning migration fear into a project plan

The teams that lose candidates usually have decent data. Their real problem is treating the migration as a quiet IT task and forgetting that recruiters have to come along. Every hard part of a switch has a known countermeasure, from capturing attachment files at export to naming an executive sponsor.

In practice, a switch is just ordinary project work with a known sequence. Where you land matters as much as how carefully you move: an ATS that already fits your stack removes most of the risk before you start, and a genuinely free core lets you prove the whole workflow with your own data first, so by the time you move it for real, you already know exactly what happens.

FAQ: Switching ATS without losing candidates

How long does an ATS migration take?

Anywhere from a few hours to a few months. On a self-serve platform an HR professional can be live in hours, while a large organization with heavy integrations usually needs two to four months, with most mid-sized teams landing somewhere in between at a few weeks. Data volume and integration count decide where you fall.

Will I lose candidate data when switching ATS?

You shouldn't, as long as you treat candidate records as relational and move the original files. Data loss usually comes from flattening records to CSV, which strips stage history and scorecard ratings, or from attachment links that expire before you download them. Validate record counts against the old system at cutover, and the risk drops to near zero.

Can I run two ATS in parallel?

Yes, and it is the safest way to switch. Keep the old system live for in-flight candidates while new applications flow into the new ATS, run both for about one to four weeks, then reconcile and cut over on a hard sunset date. The sunset date is what stops an open-ended parallel run from drifting permanently.

How do I export data from my old ATS?

Request a structured, machine-readable export such as CSV or JSON, covering your candidate and application records, including stage history and the original attachment files. Test that the file is actually usable before you sign with a new vendor, since some providers charge per request and take five to ten business days. Under GDPR you also have a portability right, with a one-month response window.

What integrations break during migration?

Most often the connections to your HR system and job boards, usually through expired OAuth tokens or a deprecated API version. Breakages are quiet: a hired candidate can stop syncing to payroll for weeks before anyone notices. Re-test every integration right after cutover, before you rely on it.