The steps
About 4 hrPick the cutover window
Schedule the migration between two active searches if at all possible. If one role is mid-flight, finish that role on the spreadsheet first, then migrate everything before the next role opens. Mid-search migrations are where candidates get lost.
Export the spreadsheet to CSV with one row per candidate
Open the spreadsheet, save a copy named with today's date, and verify each row represents exactly one candidate. Merge any duplicate rows manually before export. The CSV is the source of truth for the import.
Map spreadsheet columns to ATS fields
Write down each ATS field on the left and the matching spreadsheet column on the right. Skip ATS fields with no source column for now. This map is the import spec. Aim for matching name, email, resume URL, current stage, recruiter notes, and rating at minimum.
Test-import a single role first
Pick one role with under 20 candidates and import only that role's rows. Open the resulting pipeline and verify every field looks right end-to-end. Fix anything wrong in the field map, then re-test. Do not proceed to the full import until the test role looks identical to the spreadsheet.
Verify every resume link before bulk import
Resumes stored as cloud-drive links break under permission changes more often than people expect. Run a link-checker over every URL in the resume column before the full import, and either re-upload broken ones or mark those candidates with a 'resume unavailable' flag.
Import the rest of the active candidates
Run the full import with the validated field map. Open the resulting pipeline view, sort by last activity, and spot-check the top 20 candidates. If anything looks wrong, fix it now — fixes after candidates start moving stages are painful.
Import historical candidates as a separate archive batch
Set their stage to 'archived' or 'closed' on the way in. This keeps the live pipeline clean and preserves the searchable history for future roles. Most ATS platforms have a separate candidate database view for this.
Run both systems in parallel for one live role
Open the next real role inside the ATS while keeping the spreadsheet read-only. Move applicants through the ATS only. Watch for any field you instinctively want to update on the spreadsheet — that is a missing ATS configuration you need to add.
Notify active candidates about the platform change
Send one short message to every candidate currently in an active stage: platform is changing, here is the new portal link, no action needed on your end unless you want to update your profile. One message, one link, no apology.
Archive the spreadsheet read-only
Move the spreadsheet to a 'do not edit' folder and remove edit access for everyone on the team. Leaving it editable creates a slow data leak where someone updates the spreadsheet instead of the ATS for the next six months.
Migrating from a hiring spreadsheet to an applicant tracking system is one of the highest-anxiety small-team software changes, and one of the lowest-actual-risk if done in the right order. The risk is not the data — it is the timing. This playbook walks through the migration in the sequence that loses zero candidates, in a weekend.
Why does the order of the migration matter more than the tool choice?
Most small-team migrations fail in the same place: they happen mid-search, with one role half on the spreadsheet and half in the new applicant tracking system. Candidates land twice, get advanced twice, get rejected twice, and lose trust in the process. According to candidate experience research published by organisations like the Talent Board and summarised in the LinkedIn Global Talent Trends reports, a confusing communication trail is one of the strongest predictors of a candidate withdrawing from a process voluntarily — and a half-migrated funnel is almost guaranteed to produce a confusing communication trail.
The fix is timing, not tooling. Migrate between two active searches. Finish the current role on the spreadsheet, archive it, and start the next role inside the ATS. That single rule eliminates the majority of migration mistakes before they happen.
What does a clean migration actually look like?
The whole job has five phases: prepare, map, test, import, parallel-run. Each phase has a clear exit condition. If a phase does not meet its exit condition, the next phase does not start.
The prepare phase ends when the spreadsheet exists as a clean CSV with one row per candidate, every duplicate merged, and a dated backup saved somewhere read-only. Most teams skip the deduplication step because it looks like busywork. It is the step that prevents two-records-one-candidate confusion for the rest of the migration.
The map phase ends when every ATS field has a matching spreadsheet column written down (or a deliberate "leave blank" decision). The map is the import spec. It also exposes the fields the team has been tracking informally — handwritten notes, scribbled ratings, side channels — that should either become ATS fields or be deliberately dropped.
The test phase ends when one role with under 20 candidates has been imported and the pipeline view matches the spreadsheet exactly. This is the single most important quality gate in the migration. A failed test import is cheap to fix; a failed full import is not.
The import phase ends when active candidates are inside the ATS, every resume URL has been verified to resolve, and historical candidates have been imported as a separate "archive" batch with stage set to closed. Treating active and archive as separate imports keeps the pipeline clean.
The parallel-run phase ends when one live role has gone through at least one stage transition entirely inside the ATS, with the spreadsheet read-only the whole time. That is the moment the migration is real.
How do resume files survive the move?
Resume URLs are the asset most often lost in migration. In a spreadsheet, resumes typically live as links to Google Drive, Dropbox, or a shared cloud folder. Two failure modes are common: the link points to a file the new ATS workspace cannot access (permission changes break this), and the link points to a file that was renamed or moved after the candidate applied. Both produce a candidate record in the ATS with no working resume, which is functionally worse than a candidate not imported at all — because the empty record looks complete.
The fix is a link-check pass before the bulk import. Run a simple script or a free link-checker over every URL in the resume column, mark any broken links, and either re-upload the resume from email or local files or flag the candidate with a "resume unavailable" note. Spending an hour on this step prevents a recruiter discovering, six weeks later, that an interesting candidate's resume cannot be retrieved.
The migration step everyone wants to skip is the link-check pass on resumes. Skipping it is the migration mistake everyone regrets.
What should the team tell candidates during the move?
One message, one link, no apology. Active candidates need to know two things: the platform is changing, and where to log in to update their profile if they want to. Inactive and historical candidates do not need a message at all — the migration is invisible to them.
The message itself should be short. Three lines. The recruiter's name at the bottom. No marketing, no apology, no over-explanation. The reason silence increases candidate ghost rates more than bad news is that silence reads as disinterest; a clear short note reads as a working process. Industry candidate experience research from SHRM and the Talent Board has shown for years that even bare-minimum communication during process changes outperforms total silence.
What about historical data — bring it or leave it?
Bring it, in a separate import. Historical applicants are the closest thing a small recruiting database has to compounding value: every role a candidate did not get hired for is a role they might be a fit for next year. Importing them as an archive batch — stage set to closed, marked with a tag like "imported-from-spreadsheet" — preserves the searchable history without polluting the live pipeline.
This is also where the team's first round of free distribution comes from. An ATS with a candidate database lets you search by tag, role type, or last-active date and pull up a list of warm-but-not-hired people the next time a similar role opens. That kind of warm sourcing is one of the lowest-cost-per-hire channels available, and the spreadsheet quietly buried it.
A sample column-to-field map
The exact mapping depends on what your spreadsheet has, but this is the shape most teams end up with on the first pass.
| Spreadsheet column (typical) | ATS field | Notes |
|---|---|---|
| Name | Candidate name | Required. Trim leading/trailing whitespace. |
| Candidate email | Required. Lowercase before import to dedupe. | |
| Resume link | Resume URL or file | Link-check before import. Re-upload broken ones. |
| Role applied to | Job | ATS jobs must exist first. Create them before import. |
| Stage | Pipeline stage | Stage names must match. Map case-insensitively if needed. |
| Notes | Comments | Multi-line comments may need a newline-to-paragraph pass. |
| Rating | Rating | If 1–5, leave as-is. If text (great/good/maybe), translate first. |
| Source | Source | Optional. Useful for reporting later. |
| Date applied | Applied at | ISO format if the ATS is strict (most are). |
After the cutover
Three things happen in the first two weeks after a clean migration. The first is that one or two missing fields surface — fields the team was using in the spreadsheet without realising. Add those to the ATS as custom fields or in the comment thread. The second is that the team has to actively resist updating the spreadsheet out of habit. The fix is removing edit access from everyone on day one. The third is that resume links start pulling their weight again, because they now sit on records the whole team can see.
By week three, the spreadsheet stops being a fallback. By week four, it has been forgotten. That is the success criterion.
Closing thought
A migration done right is invisible to candidates and forgettable for the team. A migration done wrong haunts a year of hiring. The difference between the two is twenty minutes of column mapping, an hour of link checking, and the discipline to migrate between searches rather than during one. None of that is hard. The only reason teams put off the migration is because the spreadsheet still seems to be working — which is true, until it isn't.
If you are ready to start, create a free RecruitIn workspace — no credit card, branded career page live in minutes. To compare options before you commit, read our buyer's guide to free and affordable ATS. And once the migration is done, the natural next question is when to upgrade off the free tier — covered in free ATS vs paid ATS: when does upgrading actually pay off. Pricing details are on the pricing page.
