· 4 min read · The HumanR team
From Excel to payroll without a migration project
Choosing an HR system is the easy part. Here is how a payroll workbook actually gets moved, what turns up inside it, and the one test that decides go-live.
The system is not the project. The workbook is.
Most companies that run payroll from a spreadsheet are not there because they never looked at software. They looked, and then they looked at the workbook: twenty years of staff records, expiry dates, leave balances and salary structures, kept going by busy people under pressure. Moving that felt like a project of its own, so the workbook stayed.
That instinct is right. Choosing an HR system is easy. Getting your data into it is where most rollouts stall, and a vendor who skips that part in the sales conversation is telling you something. This post is how we do it, including the parts that usually stay out of the deck.
Send the workbook as it is. Do not tidy it first.
The first thing to ask for is the actual files: the staff workbook, the leave tracker, the salary sheet, and whatever else has quietly become load-bearing. Not a specification of them, and not a cleaned-up copy.
The mess is diagnostic. It shows how the workbook was really used: which columns people trust, which they abandoned, which sheet the payroll officer believes when two disagree. Cleaning it first usually destroys exactly the evidence that stops a bad assumption reaching payroll.
From those files you should get back a written, sheet-by-sheet account of your own data before anyone talks about sequence or dates: what is real data, what is a formula mirror of another sheet, what is stale, and which decisions only you can make. That account is useful whether or not you go on to buy anything.
What is inside every long-lived HR workbook
None of this is a criticism. Every workbook maintained for years has these, and naming them in advance changes how a migration is sequenced:
- View sheets that went stale. Tabs that are the main register filtered by hand (new joiners, temporary staff, headcount) were right the day they were made. In one workbook we migrated, a 122-row temporary-staff tab was really 23 people.
- Reused staff numbers. Someone leaves, the number goes to the next joiner, and two people now share the key half your other sheets use.
- The same person twice, in two states. On the active sheet and the terminated sheet, or copied rather than moved when they left.
- Dates Excel quietly changed. Typed as day/month, stored as month/day: 2 December filed as 12 February.
- Broken formulas hiding real records.
#REF!cells spread quietly. Any total reading them has been wrong for a while. - Two sheets that disagree about someone's pay. These are decisions for you, not for whoever is loading the data.
Nothing is saved until you have read what saving would do
Nobody should be retyping records, and you should not be reformatting your workbook into a vendor's template either. We load the files ourselves, with tooling built for it, in four phases: the organisation first (companies, departments, sites, leave types, holidays), then people and their documents, then pay, then history.
Each load runs first as a dry run that saves nothing and reports exactly what it would do: how many rows are new, how many change an existing record, how many change nothing, and which rows failed and why. Then it commits. A few guarantees make that safe to repeat:
- A blank cell means “not filled in”, never zero, so a blank salary cell will not wipe a package.
- A load never deletes. Anything not in the file is left as it was.
- Each load lands completely or not at all.
- Loading the same file twice changes nothing the second time, so the live workbook can be reloaded while both systems run.
The test that decides go-live: a month you have already paid
Everything above is preparation for one test. Take a month you have already paid and consider correct, regenerate it in the new system, and reconcile it against your own sheet. Not a sample: every payslip, line by line.
Then argue about every difference before real money moves, not after. In the migration we documented, 706 payslips were reconciled this way, and every unexplained difference turned out to be an arithmetic error in the source sheet. Which one is right is still your ruling to make. Go-live is when a regenerated month reproduces your own figures to the cent, and every exception has a named cause and a decision against it.
Then switch the spreadsheet off
The last step is not technical. Name a cut-over date and make the old workbook read-only on it. A system running alongside a spreadsheet nobody retired is the most common way an HR rollout quietly fails: the two drift, people go back to the one they know, and a year later you have two sources of truth instead of one.
What makes that decision easier is what is waiting on day one. Reports replace the hand-filtered tabs and are correct the moment you open them. The expiry dashboard is populated from the documents you sent: in the migration we documented, 5,533 documents with expiry dates landed on one board, and hundreds of them had already expired without anyone having a list.
Who does what
| We do | You do |
|---|---|
| Read every sheet, including the hidden ones | Send the files untidied |
| Run the loads, dry run first | Rule on the contradictions only you can settle |
| Reconcile a paid month payslip by payslip | Pick the month, and decide each mismatch |
| Train your people on your own data | Name the cut-over date and retire the old sheets |
We will not quote a number of weeks before seeing your files, because your data decides that, not the install. Send them, and the first thing you get back is the written account of what is in them.