WHAT EXPORTS, WHAT DOES NOT, AND THE ORDER TO DO IT IN.
BEFORE YOU MOVE
What exports, and what does not.
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:
Comes out reliably
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”.
Comes out, with work
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.
Rarely comes out usably
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.
We move your candidates across, free of charge. Then fourteen days of the whole desk.
Start free — 14 days →Eleven steps, in this order.
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.
Read your notice period and your exit terms before you talk to anyone
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.
Ask for a full export now, while you are still a customer
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.
Open it and count
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.
Check the documents actually match the people
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.
Decide what you are deliberately not bringing
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.
Write down what a duplicate is
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.
Insist the new system keeps a reference back to the old one
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.
Do a rehearsal with a subset
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.
Run both systems in parallel for a fortnight
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.
Take a final export on the last day, and keep it
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.
Tell candidates, and check your privacy notice still describes reality
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.
Start the eleven steps with a desk to move into. Free for a fortnight.
Start free — 14 days →Four questions to ask before you sign again.
“Can I export without asking you?”
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.
“What is in the export, exactly?”
Ask for a table list, and ask whether documents are included in the same download. “Your data” is not a specification.
“Is anyone else's data in mine?”
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.
Your candidates. Moved across for nothing. Fourteen days, no card.
Start free — 14 days →The export is a feature, not a favour.
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.
A feature, not a favour.
The account owner requests a full export of the organisation from inside the product and downloads it when it is built. What arrives is a zip: one CSV per table, a manifest recording exactly what was written and how many rows, and the documents themselves foldered by kind.
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.
Two independent tenant guards
Only your organisation's data is exported.
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.
Requesting it is an owner decision
Access is controlled and auditable.
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.
Imports carry their origin
Every record keeps its source.
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.
The seat is £25 a month. The system you cannot leave is costing you more than that.
82p a day per recruiter — and here the export is a feature, not a favour.
Nobody stays on an ATS they have outgrown because they like it. They stay because getting the data out looks worse than putting up with it for another year. So price the year. A seat is a fraction of one placement fee, the first fourteen days cost nothing, and you can run both systems side by side for that fortnight without paying for either. Then ask what leaving ATS Engine would cost you: one CSV per table, a manifest of exactly what was written, and every document in its original file, exported by the account owner at any time. The same on the way out as on the way in, which is the only honest way to sell a migration.
- Run both for a fortnightFourteen days free, so the comparison happens on your data rather than in a demo.
- The export is built inOne CSV per table, a manifest, and every document. Owner-triggered, any time, staying or leaving.
- The rate falls as the desk grows£25, then £22.50, then £20 a seat. Published brackets, not a negotiation.
Fourteen days free before you pay anything, and no card to start. Subscribe when it has earned it, and cancel in PayPal whenever you like.
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.
Export the whole desk whenever you like. Try it free for fourteen days.
Start free — 14 days →More for agency owners.
Compliance by sector
The eight credential regimes UK agencies actually have to track, the renewal cycle for each, and the trap in every one.
Temp and shift desks
Six things that break when a temporary desk is run on software built for permanent placement.
Candidate data retention
How long an agency can keep a CV, where the answer really comes from, and the five questions that decide it.
Move the desk without losing the history.
Fourteen days of the whole desk, no card, and your data stays exportable the whole time.