For years the team worked from a shared spreadsheet: one tab per client, a column for status, a column for notes and colour codes that only two people really understood. Then the switch to a new system is planned, someone exports everything, and three weeks later nobody can tell which candidates were already sent to which client, why someone was rejected last year or who promised to call back. The tool changed, but the history did not come along. This article explains how to move from spreadsheets to an Applicant Tracking System without losing candidate history: what to migrate, how to clean and map the data, how to keep submission history intact and how to switch over on one fixed date.
Every segment has its own reason to get this right. Recruitment agencies carry years of candidate and client history that is their real asset. Staffing teams often run separate lists for available workers, current assignments and certificates. Secondment firms need to keep end dates of running assignments in view during the move. Executive search consultants hold long-running, confidential relationships that must not be lost or exposed. In-house recruitment teams want earlier applicants and hiring-manager feedback in one place instead of in personal files.
What usually goes wrong when teams leave spreadsheets
- Everything is imported at once, including years of outdated or unlawful records that should have been deleted
- The same person appears three times because each recruiter kept their own list
- Status values from the spreadsheet do not match the pipeline stages, so candidates end up in the wrong place
- Notes lose their dates and authors, which makes old remarks look like recent ones
- The record of who was submitted to which client disappears, so the risk of double submission returns
- The old spreadsheet stays in use next to the new system, and nobody knows which one is right
Decide what you move and what you leave behind
Not everything in a spreadsheet deserves a place in the new system. Start with what is still active: open vacancies, candidates in a running process, placements that are still in a guarantee period or assignment, and clients with current terms. Then add the candidates you are likely to contact again, such as recent applicants and runner-ups. Records that are past their retention date, or for which you no longer have a valid reason to keep them, should not be migrated at all. A migration is a natural moment to start clean instead of carrying old problems into a new tool.
Clean before you import, not after
- One person, one row — combine the lists of different recruiters and merge duplicate candidates before the import, using e-mail address and phone number as the main check
- One spelling per value — align job titles, locations and skills with your shared skills and tag list
- One format for dates — convert availability, notice periods and contract end dates to real dates instead of text such as “after summer”
- One source per candidate — keep the original candidate source where it is known, and mark it as unknown rather than guessing
Cleaning in the spreadsheet is faster than cleaning hundreds of records one by one in the new system afterwards, and it shows you early how much of the data is actually usable.
Map columns to fields and statuses to pipeline stages
Write down, column by column, where each piece of information will live in the Applicant Tracking System: candidate record, client record, vacancy or note. Do the same for every status value. “Sent”, “CV out” and “with client” probably all mean the same stage, and each stage should match the written entry criteria you agreed for it. Free-text notes are best imported as notes with their original date and, where known, the recruiter who wrote them, so the history stays readable in the right order.
Keep the submission history intact
The most valuable part of a recruitment spreadsheet is often the least structured one: which candidate was presented to which client, for which vacancy and on which date. Move this history as separate submission records rather than as one long note. Only then can the new system warn you when a candidate is about to be submitted to the same client twice, and only then can you show later when and with whose consent a profile was shared.
Test with a small set first
Before moving everything, import a small, representative set: for example one team, one large client or the vacancies of the last three months. Compare the counts with the spreadsheet, open at least twenty records at random and check whether stages, dates, notes and submissions look the way the recruiter remembers them. Fix the mapping, then repeat. Two short test rounds are cheaper than one large import that has to be undone.
Switch over on one fixed date
Agree a cut-over date with the whole team. From that day, new work happens only in the Applicant Tracking System. Set the old spreadsheets to read-only, store one final copy in a protected place for as long as you really need it, and delete it in line with your retention rules. Running both side by side “for a while” is how teams end up with two versions of the truth.
Give every active candidate an owner and a next step on day one
An imported record without a responsible recruiter is easy to forget. Right after the switch, make sure every open vacancy has a single owner and every candidate in a running process has a next-action date. Use the first weekly pipeline review after the move to walk through the active pipeline together and correct what still looks wrong.
Measure it with your own data
Count from your own records: how many rows were in the spreadsheets and how many records were created, how many duplicates you merged, how many records were deliberately not migrated because of their retention date, what share of active candidates has an owner and a next-action date, and how many issues the spot checks found per test round. Report the number of records behind each figure. Do not rely on general claims about migration speed or savings; your own counts show whether the move was complete and correct.
Where artificial intelligence may help — and where it must not
Artificial intelligence may suggest how spreadsheet columns map to fields, point out rows that probably belong to the same person, or propose tags based on old notes. It stays a helper. Artificial intelligence does not replace recruiters, does not decide which candidate data may be kept and does not merge records or delete history without a person checking it. The decisions stay with the team; the Applicant Tracking System makes sure the result is structured, traceable and shared.
A practical start
- List every spreadsheet in use and name one person responsible for the migration
- Decide which records are active, which are worth keeping and which will not be migrated
- Merge duplicates and align spellings, dates and sources in the spreadsheet itself
- Map every column to a field and every status value to a pipeline stage
- Import a small test set, spot-check twenty records and adjust the mapping
- Pick a cut-over date, set the spreadsheets to read-only and give every active record an owner
Your history is worth moving properly
A spreadsheet holds years of conversations, submissions and client knowledge. Moved with care, that history becomes searchable, shared and protected in one place instead of disappearing in the switch. Explore the product or book a demo — we show how candidate records, clients and the pipeline are set up in BoldATS for your segment.