Most agencies do not leave an applicant tracking system because they found a better one. They stay in a system they have stopped liking because nobody is confident the book will survive the move — and that uncertainty is worth more to an incumbent vendor than any feature on their roadmap.
This page is the practical version: what actually comes out, what never comes out cleanly, and the order to do things in so you find out while you still have both systems.
Almost every system will give you a candidate export. The question is never whether you get something — it is which of the things you actually rely on are inside it. In rough order of how reliably they survive:
Candidate names, contact details, and the structured fields the system defined itself: status, owner, source, created date. Client and contact records. Job or vacancy records. This is the part every vendor means when they say “you can export your data”.
CVs and attachments — usually as a separate folder with filenames that may or may not tell you whose they are. Application history, if the system kept it as records rather than as a status field it overwrites. Custom fields, if you can get a list of what they were.
Consultant notes and activity timelines. Email threads held inside the system. Anything derived rather than stored — scores, rankings, matches. Placement and financial history, which is often in a different module with a different export, or none.
The pattern is consistent: the closer something is to the daily judgement of your consultants, the less likely it is to be portable. Which is also, not coincidentally, the part of the record that took years to accumulate.
The order is the point. Steps 1 to 4 happen while you are still a paying customer of the system you are leaving, because that is the only time you have any leverage at all.
Find the number of days, whether the contract auto-renews, whether there is a charge for an export, and how long the data is retained after the account closes. Some contracts specify a window — often 30 days — after which the vendor may delete everything. That window, not your project plan, is the real deadline.
Not a sample. The whole thing, including documents. Do this before you announce anything. An export request from a happy customer is routine; the same request from a leaving one is a support ticket somebody is in no hurry to finish.
How many candidate rows did you get, and how many candidates does the system say you have? If those two numbers differ, find out why before anything else happens. The usual causes are archived records, a per-user scope on the export, or a row limit nobody mentioned.
This is the step most often skipped and most often regretted. Open the attachments folder and pick twenty at random. Can you tell, from the export alone, which candidate each belongs to? If the link is a database id that appears nowhere in the CSV, you have files and you have people and nothing joining them.
A migration is the one clean opportunity you will get. Candidates nobody has spoken to in four years, duplicate records, clients that no longer trade, roles filled in 2019. Moving them costs money at every stage and makes every later search worse. It is also the moment to apply a retention policy you may have been meaning to write anyway.
Same email? Same name and date of birth? Same mobile? You will be asked, and the answer determines how many records you end up with. Agree it before the import rather than during it.
Every imported record should carry the source system's own identifier. Without it there is nothing to recognise a re-import by, and a re-run after a correction, an outage or a fresh export next month inserts everything a second time. This is cheap to do on day one and effectively impossible to retrofit once real records have moved on.
A few hundred records, including the awkward ones: the candidate with four CVs, the one with an apostrophe in their name, the client with two trading names. Then look at them in the new system as a consultant would, not as a spreadsheet.
Read-only on the old one if you can. The overlap is not wasted money; it is the only period in which you can answer “where did that note go?” without having to guess.
Not in the new system — as a file, somewhere durable, with the date on it. It is your only recourse against something nobody noticed was missing until a client asks about a placement made two years ago.
Where their data is held is something your privacy notice tells them, and it has just changed. Handle this as part of the migration rather than as an afterthought — and see candidate data retention for what the ICO expects a retention policy to look like.
If the answer is “raise a ticket and we will produce it”, your data is available at your vendor's convenience. That is a different arrangement from the one their marketing describes.
Ask for a table list, and ask whether documents are included in the same download. “Your data” is not a specification.
Multi-tenant systems hold every customer in the same tables. Ask what stops a stray row from another agency appearing in your export — and what stops yours appearing in theirs.
The fourth question is the one to ask yourself: how long would it take to leave this system, starting today? An honest answer to that is the most useful number in the whole evaluation, and it is the one nobody puts in a comparison table.
An account owner can request a full export of the organisation from inside the product and download it when it is built. It is queued rather than produced inside a page load, because twenty-six tables and a document folder is not something to make somebody wait on a browser for.
What arrives is a zip: one CSV per table, a manifest.json recording exactly what was written and how many rows, and the documents themselves foldered by kind so that a CV is distinguishable from a compliance certificate when you open it. Stored credentials — your own mailbox passwords, for instance — are redacted rather than exported, because encrypted values are useless to you and are one leaked key away from being live.
The export applies the same organisation scope a web request does, and then checks every single row against your organisation id, aborting the entire export rather than emitting one foreign record. The second check exists because the first one can be broken by a refactor years from now, silently.
Any recruiter can read the pool one record at a time — that is the job. Taking the whole book in one archive sits behind user management, because it is exactly what a departing employee wants on their last afternoon.
Candidates, clients, applications and job postings each hold the system they came from and that system's own id for them. Re-running an import corrects records rather than duplicating them — which matters here, because catching duplicates is the thing this product claims to be good at.
Migrations in are done with you rather than left as a file upload: we agree the duplicate rule, rehearse on a subset, and check the documents landed against the right people before the full run. If you want to see the shape of an export before committing to anything, ask and we will show you a real one.
One thing that is true of ATS Engine and worth stating plainly: your candidates are never pooled with another agency's, and are never used to fill anybody else's roles. There is one organisation boundary in the system and nothing is allowed to cross it — which is also why the export can guarantee that what you get back is only ever yours.
The eight credential regimes UK agencies actually have to track, the renewal cycle for each, and the trap in every one.
Six things that break when a temporary desk is run on software built for permanent placement.
How long an agency can keep a CV, where the answer really comes from, and the five questions that decide it.