How to Move From a Spreadsheet to an ATS Without Losing Candidates

To move from a spreadsheet to an applicant tracking system without losing candidates, clean the sheet first, map every column to a field in the new system, import five test rows before the full file, match your stage names to the new pipeline, check counts afterwards, and keep the old sheet read-only for a month.

Why spreadsheet migrations go wrong

Most small teams start hiring in a spreadsheet, and it works until it does not. Then comes the move to an applicant tracking system, and the move is where candidates get lost. The causes are ordinary. Names are spelled three ways, the same person appears on two rows, emails are missing, stage columns hold free text such as called, maybe, or ask Priya, and notes live in cells that were never meant for long text. When that file is pushed into a system in one go, some rows are rejected, some are merged, and some arrive in the wrong stage, and nobody notices because nobody counted. The fix is not a clever tool. It is a short, boring process: clean, map, test, import, check, and keep the old sheet as a safety net. This guide walks through that process for small and mid-size teams, with a mapping table, a worked example using example numbers, and a list of mistakes to avoid. For an overview of what these systems do, see /applicant-tracking-system, and if you are still deciding whether to pay at all, see /free-applicant-tracking-system. Rules on keeping candidate data differ by country, so treat the privacy points as prompts to check local law.

Step 1: decide what is worth moving

You do not have to move everything. Start by splitting the sheet into three groups. Group one is live: people in an active process for an open role. They must move, with their stage and notes. Group two is recent: people from roughly the last year or two who you might want to contact again. They are worth moving, usually as a plain list with name, email and the role they applied for. Group three is old: people from years ago, with no recent contact. Many teams choose not to move these, because holding personal data you have no reason to keep can create legal duties, and the rules differ by country. If you do keep them, make sure you have a reason and a retention limit. Count each group before you start and write the three numbers down, since you will need them for your final check. Also decide who owns the migration. One person should run it from start to finish, because a shared job with no owner is the usual way a file ends up half imported. Set a date for the cutover and tell the team that after that date the sheet is read-only.

Step 2: clean the sheet

Cleaning takes the longest and prevents the most trouble. Work through these checks in order. Make sure every row has one person, not two names in one cell. Split full names into first and last if your target system asks for it. Lowercase and trim every email, and remove spaces. Find rows with no email and decide what to do with them: find the email, or hold them back for manual entry. Find duplicates by sorting on email and by sorting on name, and merge rows that are the same person, keeping the most recent notes. Standardise the stage column to a short list, for example New, Screened, Interview, Offer, Hired, Rejected, and turn free text into one of those values. Move long comments into a single notes column. Put one role per row, and if one person applied to two roles, either use two rows or write the second role in notes, according to how your new system works. Save a copy of the original file before you change anything, and name the cleaned file clearly. Keep the original untouched.

Step 3: map columns to fields

Open the import screen or the documentation of the new system and list the fields it accepts. Then map each of your columns to a field, and decide what to do with the columns that have no home. A mapping table makes this visible and lets a second person check it. Here is an example only.

The last rows show a common problem. Not every column has a matching field, so you must decide whether the data matters enough to keep as text or can stay in the archived sheet. Avoid moving sensitive items you do not need. If the target system needs a column to exist before it can import, such as a job to attach candidates to, create those records first.

Step 4: map your stages

Stage names are where meaning is lost. In a sheet, stage is whatever someone typed. In an applicant tracking system, stage drives lists, counts and reports. Write out every value in your Status column and say where it goes. Phone call done becomes Screened. Onsite becomes Interview. Verbal offer becomes Offer. Not a fit, no reply and withdrew all become Rejected, but keep the reason in notes so you do not lose it. Anything unclear goes to New, and a person looks at it later. Check how the new system handles unknown values, because some will drop the row, some will put it in the first stage, and some will fail the whole file. Rezumz, for example, matches common names from other tools, such as Phone Screen to Shortlisted and Offer Extended to Offer, and sends anything unrecognised to New, as described in its documentation. Other systems differ, so read the import notes of the one you chose and, if in doubt, test with a small file. Keep a short table of your own mapping so everyone agrees what the stages mean after the move.

Step 5: test with five rows

Never import the full file first. Make a test file with five rows that cover your awkward cases: a normal row, a row with a long note, a row with an accent or non-English name, a row with no email, and a duplicate of another row. Import it. Then open each of the five candidates in the new system and compare with the sheet, field by field. Check the name and its accents, the email, the stage, the job, the notes and any dates. Check what happened to the row with no email and the duplicate: was it skipped, merged or added twice? Write down what you learn and adjust the cleaning rules. If the system lets you delete the test candidates, do so before the real import. If it does not, be aware that those five will remain, and plan for it. Repeat the test until the five rows land exactly as you want. This step usually takes less than an hour and it removes most of the risk. Skipping it is the single most common cause of a messy first week.

Step 6: import, then count and spot-check

Now import the real file, in batches if the system has a limit per upload. Some tools cap a single CSV at a certain number of rows, so check the limit and split the file if needed. After each batch, count. The number in the new system should match the number of clean rows you sent, minus the rows you know were skipped as duplicates. If the numbers differ, find out why before you go on. Then spot-check twenty candidates picked at random, plus five of your most important live ones, comparing stage and notes with the sheet. Look at the oldest and newest rows, since errors cluster at the ends of files. Check that nobody was emailed automatically by the import, and ask the vendor if you are unsure, because a bulk import that sends messages to old candidates would be a bad surprise. A CSV carries no CV files, so plan to attach CVs for your live candidates by hand or from your email, and note who is responsible. Finally, tell the team the import is complete and that the new system is now the place to work.

Worked example with example numbers

These numbers are examples only. A 30-person agency keeps a sheet with 640 rows. After sorting, they find 85 live candidates, 310 recent ones and 245 old ones from more than three years ago. They decide not to move the old group, so 395 rows go forward. Cleaning removes 22 duplicates, leaving 373, and 14 rows have no email. They find 9 of the emails in their inbox and hold 5 back for manual entry, so 368 rows are ready. They test five rows, find that long notes are cut at a limit, and shorten the notes column before the real import. They import in one file. The new system shows 368 candidates, which matches. The spot-check of 25 candidates finds one stage error, where Verbal offer was mapped to New instead of Offer, and they fix the mapping and re-check all rows with that value. The old sheet stays read-only for a month. At the end of that month nobody has needed it, so they archive it with restricted access and set a date to delete it according to their retention rules.

Common mistakes during migration

The biggest mistake is importing the raw sheet and fixing problems afterwards, because cleanup inside a live system is slower and riskier than cleanup in a file. The second is skipping the test import. The third is trusting that stage names will match. The fourth is leaving out the live candidates' CVs and notes, then asking people to resend. The fifth is letting two systems run in parallel for months, so that updates go to the wrong place. Set a cutover date and keep to it. The sixth is moving personal data you have no reason to keep. The seventh is giving everyone full access on day one, when hiring managers may need view-only. The eighth is forgetting to export before you switch, so a mistake cannot be undone. The ninth is not counting. The tenth is failing to tell candidates and colleagues about the change. If you later want to compare other tools, see /compare for how we position ourselves, and check every competitor's current import features and limits on their own site, since they change.

Where Rezumz fits

Rezumz is a hiring workspace for small and mid-size hiring teams. For a move from a spreadsheet it can import candidates from a CSV on a job page. The file needs a Name column, or First name and Last name, and Email, Stage and Notes are used when present. Imported candidates have no match score until you add their CVs, people already on the job with the same email are skipped, up to 500 candidates can be imported at a time, and nothing is emailed during import. You can also export a job or all jobs as a CSV, so the way out stays open. After the move you can add CVs by email through a private CV inbox, score each CV against the job requirements, shortlist, schedule, collect scorecards and prepare offers. It suits small and mid-size teams, and the Team plan is for four or more recruiters. It does not suit large enterprises needing deep HRIS or payroll links, and it does not do one-click multiposting to job boards. Prices: a free plan with 2 free candidate analyses, $29 a month, $199 a year, or a limited $499 lifetime option; Team is $79 a month or $699 a year for up to 10 teammates. See /pricing and try /demo.

When not to migrate yet

Do not migrate in the middle of a rush. If you have four offers going out this week, finish them first, then move. Do not migrate if your sheet is too messy to trust and nobody has time to clean it, because importing mess only moves the mess. Do not migrate if you hire so rarely that a sheet still serves you, or if the real problem is a lack of applicants, which software will not fix. And do not migrate until you have chosen the tool on evidence. Run a trial first, as set out in our article on a 30-day trial with real hiring, before you move any real data. If you do go ahead, remember that rules on holding and moving candidate data differ by country, and that moving data to a new provider is a form of processing that may need notice, a contract and a lawful basis. Check local law, or take advice, before you move personal data to a new system.