A recruiting lead decides her company has outgrown its current system. Pricing jumped at renewal, support has gotten slower, and a competitor's product does everything the current one does, plus a few things it doesn't. She signs with the new vendor, feeling good about the decision. Three weeks later she's manually re-entering years of candidate history because the export from the old cloud based applicant tracking system came out as a tangled spreadsheet with half the custom fields missing.
This is the part nobody warns you about during the sales pitch for the new system. Switching vendors is framed as an upgrade. In practice, it's a migration project, and migration projects have a way of going worse than expected.
What actually has to move
Switching isn't just logging into a new account and starting fresh. A company using a cloud based applicant tracking system for any length of time has accumulated real assets inside it: candidate resumes, interview notes, tags built up over years, and historical records that might matter for compliance purposes. All of that has to come out of one system and into another, intact, which is a much harder problem than most people expect going in.
Where exports fall apart
Custom fields are ephemeral by nature. If your old system had a way to tag candidates with specific categories, custom fields, or notes in a particular format, a standard export usually flattens all that into plain text or leaves it out entirely. Instead of the tidy database you expected to migrate to, the new system gets a pile of unstructured data.
Resume formatting gets lost. A cloud based applicant tracking system sometimes stores resumes as parsed, searchable text rather than the original file. An export can return that parsed text without the actual resume document attached, meaning the new system can't re-parse anything properly because the source file is gone.
Historical stage data disappears. Knowing that a candidate from two years ago made it to a final interview round can matter later. Exports frequently reduce this down to "hired" or "not hired," losing the specific path a candidate took through the pipeline.
A question to ask before you ever sign with the old vendor
This is really a question that should've been asked at the start of the original contract, not realized halfway through a migration: what does a full export actually look like, and has anyone tested it. Best cloud based applicant tracking system vendors willing to show a sample export upfront, before you've committed to anything, are giving you information most companies only discover the hard way.
What to ask the new vendor instead
The new vendor has every incentive to make switching sound easy. A few specific questions cut through that:
Can they import custom fields and tags, or only standard resume data?
Do they support bulk resume re-upload if the export comes back as parsed text without files?
Has their team handled a migration from your specific old vendor before, and can they describe what typically breaks?
What’s the realistic, not optimistic, timeline for getting historical data fully usable in the new system?
Some small business applicant tracking software promises a rapid same-week migration, which simply isn’t possible for larger, more complex accounts. It’s worth asking for a timeline that reflects your actual data volume, not a generic estimate.
Running both systems in parallel
A cleaner approach than a hard cutover is running the old and new systems side by side for a few weeks. Keeping the old cloud based applicant tracking system handling active candidates while new applications start flowing into the replacement gives a team time to verify the migration actually worked before fully committing, rather than discovering gaps only after the old system's been shut off and the data is harder to recover.
What gets missed in a rushed switch
Cloud based applicant tracking system transitions done under time pressure, often because a renewal deadline is looming, tend to skip the verification step entirely. Data gets exported, imported, and declared done without anyone actually checking whether a sample of candidates came through correctly. This is where companies lose real information permanently, not because the migration was impossible, but because nobody checked it closely enough before moving on.
Why this matters more for compliance-heavy companies
A cloud based applicant tracking system used by companies with specific recordkeeping obligations needs extra care here. If demographic or compliance-related data doesn't transfer cleanly, or transfers in a format that's no longer properly separated from standard candidate data, that's a real problem discovered at the worst possible time, usually during an audit rather than during the calm, planned migration window when it could have been fixed easily.
Custom systems add their own complication
A custom applicant tracking system built specifically around a company's old process doesn't export cleanly into a generic, off-the-shelf cloud based applicant tracking system at all, since the data structure itself may be unique to that custom build. Often, companies in this position have to bring in a dedicated data migration specialist instead of using the standard export and import tools of either vendor. This adds cost and time that's easy to underestimate in the initial planning.
A realistic migration timeline
For a mid-sized company with several years of candidate history, a responsible migration usually looks like this: two to three weeks exporting and reviewing data from the old system, one to two weeks importing and spot-checking accuracy in the new one, and a parallel running period of a few more weeks before fully retiring the old account. Best cloud based applicant tracking system vendors promising a same-day full migration for a company with meaningful historical data are often setting an expectation that doesn't match reality.
The bottom line
A cloud based applicant tracking system that is heavily marketed on ease of switching does not often discuss what that switch really means when real historical data, custom fields and compliance records come into play. The companies that come out unscathed from a vendor change are those who asked pointed questions about exports before signing with the old vendor, tested a sample migration before committing to the new one, and built in time to verify rather than assume the data simply transferred correctly. Those that get burned are usually those who treated the move as a weekend chore rather than a real project.
FAQs
What's the biggest risk when switching applicant tracking system vendors?
Losing structured data like custom fields, tags, and historical pipeline stages during export, since most exports flatten or drop this information rather than transferring it intact.
Should companies run old and new systems at the same time during a switch?
Yes, when possible. A parallel period lets a team verify the migration actually worked before fully shutting down the old system and losing easy access to the original data.
How long does a realistic ATS migration actually take?
For a company with several years of candidate history, a careful migration typically takes several weeks total, not the same-day timeline some vendors promise during sales conversations.
Does this process matter more for companies with compliance requirements?
Yes. Compliance-related data that doesn't transfer cleanly, or loses its proper separation from standard candidate records, can become a serious problem if discovered during an audit rather than during the migration itself.
Is switching harder for companies using a custom applicant tracking system?
Often yes, since a custom build's data structure may not match standard export and import formats, sometimes requiring a dedicated migration specialist rather than relying on either vendor's built-in tools.
Top comments (0)