Moving off spreadsheets is where hiring history usually dies. Done carelessly, you arrive in the new system with names and nothing else — no record of where people came from, no rejection reasons, no trace of who nearly made it.
Look at what you actually have first
Before exporting anything, work out what is in the spreadsheet and what state it is in.
- How many records, and how many are the same person twice under different spellings or addresses?
- Which columns are filled in consistently, and which were filled in for the first 200 rows then abandoned?
- Where is information sitting in free-text notes rather than proper columns? Usually the most valuable information is there.
- Is there anything in the sheet that should not be stored at all — health details, personal opinions, notes about someone's circumstances?
That last question matters. Moving systems is a rare chance not to carry something forward. Notes written in a private spreadsheet are often not notes you would want in a system with a history log and a process for people requesting their own data.
Decide where every column goes
Map each column to a destination before importing, and decide explicitly what happens to columns with nowhere to go. The two bad outcomes are silently losing data, and a "notes" field that becomes a dumping ground nobody can search.
| Column | Decide |
|---|---|
| Name, email, phone | Straight across. Tidy the formatting first |
| Job applied for | Match to a real job record, or create a historical one |
| Stage reached | Map to your new stage names. This is where history is preserved |
| Outcome or reason | Map to your new rejection reasons. Expect a messy fit |
| Where they came from | Keep exactly as is. The hardest field to recreate later |
| Free-text notes | Decide what is worth keeping. Do not dump the lot |
| Dates | Tidy the format before importing — the Module 4 problem, in your own data |
Removing duplicates
Match on email first, then on name plus phone, then check the rest by hand.
Do not let software merge on name alone. Common names collide, and a merged record containing two different people is worse than two duplicates, because it is invisible and it stays wrong.
When merging, keep the earliest application date and the fullest history. Losing "first applied in 2022" turns a long relationship into a cold record.
The two fields people lose
How far someone got, and where they came from. Both are the input to everything in Modules 5 and 10 — contacting near-misses needs stage history, and working out which channels are worth paying for needs the source.
If your old data has no source field, do not invent one. An empty field is honest. A guessed one gets reported as fact for years.
Check before you switch off
- Import into a test area first.
- Check the counts: records in, records out, duplicates merged. The numbers have to add up.
- Check twenty records by hand against the spreadsheet — including two you know are messy.
- Run one search you do often, and confirm it finds what you expect.
- Keep the spreadsheet read-only for three months. Then delete it properly, in line with your deletion policy.
The mistake to avoid
Running both systems "for a while". Then neither is the real one, updates land in whichever was open, and after a month you cannot reconcile them. Pick a switch-over date, make the old system read-only that day, and hold the line.