Moving employee data from Excel to an HRMS: a migration checklist

Employee data in most growing businesses lives in four spreadsheets maintained by three people, with at least two date conventions and a reporting line column last updated during a reorganisation nobody finished. Everyone knows this, and everyone quietly hopes the migration will sort it out.

It will not. Migration moves what you have. If what you have disagrees with payroll, the system will disagree with payroll on day one, and people will go back to the spreadsheet — permanently.

Reconcile before you clean

Start with one check, because it determines how much work follows: does the headcount in your employee list match the number of people on last month's payroll register?

It usually does not. The differences are informative — a leaver never removed, a joiner never added, a contractor on one list and not the other, somebody counted twice under two codes. Resolve every difference before touching anything else. This reconciliation is the highest-value hour in the whole project.

The cleaning checklist

1. HEADCOUNT RECONCILED against payroll                 [ ]
   every difference explained, not just counted

2. ONE ROW PER PERSON, one unique employee code         [ ]
   duplicates found and merged, codes never reused

3. DATES normalised to one format                       [ ]
   date of joining, date of birth, confirmation date
   check for impossible values (joining before birth,
   confirmations before joining)

4. REPORTING LINES confirmed by the managers            [ ]
   not from the old chart. Ask each manager to confirm
   their list. Expect surprises.

5. MANDATORY FIELDS decided and filled                  [ ]
   agree the minimum set first; do not migrate 40
   columns because the spreadsheet had 40

6. EMPLOYMENT TYPE and STATUS standardised              [ ]
   permanent / probation / contract / trainee, and
   active / exited, with one spelling each

7. LEAVE BALANCES agreed as at a cut-over date          [ ]
   the most disputed number in any migration

8. SALARY STRUCTURE mapped to the new fields            [ ]
   component by component, checked against a payslip

9. EXITED EMPLOYEES decided                             [ ]
   migrate or archive, and whichever you choose,
   be able to retrieve their records

10. A HOLD-OUT SAMPLE of 10 employees                   [ ]
    checked by hand after loading, field by field

Leave balances are the fight

Expect this to take longer than everything else. Balances in a spreadsheet are usually the output of a formula written by somebody who has left, applied inconsistently across departments, and never reconciled with what employees believe they have.

Two decisions make it manageable. Agree a cut-over date and migrate balances as at that date, computed once, with the method written down. And communicate the balance to each employee before go-live, so disputes surface against the old system rather than against the new one — which otherwise gets blamed for arithmetic it inherited.

Reporting lines: ask the managers

Do not migrate reporting lines from an old organisation chart. Send each manager the list of people the data says report to them and ask them to confirm. This takes a week and consistently produces corrections — people who moved teams informally, a leaver still shown as a manager, someone reporting to a role rather than a person.

It matters because every approval route in the system derives from it. A wrong reporting line does not look like a data error; it looks like the system sending requests to the wrong person, which is read as the product being broken.

After loading, before trusting

1. 1

   Check the hold-out sample by hand

   Ten employees across departments and employment types, every field compared against source. Field-level errors cluster, so ten will find a systemic problem if there is one.

2. 2

   Reconcile headcount again

   System against payroll against your list. A difference introduced during loading is far cheaper to find now than in the first month-end.

3. 3

   Run one report and compare it

   Headcount by department, from the system and from the spreadsheet. If they disagree, resolve it before anybody else sees either number.

4. 4

   Freeze the spreadsheet

   Rename it, mark it as archived, and stop maintaining it. A spreadsheet kept in parallel guarantees two sources of truth and one of them will win — usually the familiar one.

What not to migrate

Resist bringing everything. Columns that were maintained inconsistently, fields nobody uses, and historic data whose accuracy nobody will vouch for all make the new system less trustworthy, not more.

Agree the minimum viable record, load that cleanly, and add fields later once the base is trusted. A sparse accurate record beats a complete doubtful one, and this is the decision businesses most often get backwards.

Sequencing all of this — what to clean, what to defer, what goes live first — is the substance of HRMS implementation work rather than a technical exercise. If you would like to see what a migration would involve against your own files, book a free demo of GullyHR software and bring the spreadsheets you actually use.

Communicate before go-live

Two messages, sent before anyone logs in. The first tells every employee their leave balance as at the cut-over date and asks them to raise a discrepancy now. The second tells managers the reporting lines the system will use and asks them to confirm.

Both invite work, and both are worth it. Every dispute raised before go-live is a dispute against the old data; every one raised afterwards is read as the new system getting it wrong, regardless of where the error came from.

The pattern to avoid

The failure mode is predictable and almost always the same sequence: load quickly to hit a date, discover the numbers disagree, keep the spreadsheet running while the data is fixed, and never quite switch off the spreadsheet. Six months later the system holds partial records and the business has two sources of truth.

The way out is to treat the cut-over as a decision rather than a date: the spreadsheet is archived on a stated day, and anything wrong after that is fixed in the system. That is uncomfortable for a fortnight and decisive for everything afterwards, which is why sequencing it properly is central to HRMS implementation rather than an administrative detail.

Keeping the spreadsheet after go-live

The instinct at go-live is to delete the old sheets so that nobody is tempted. It is the wrong instinct and it removes the only reference point you have.

Keep a frozen copy — read-only, dated, held by one person — for at least two payroll cycles. When a figure in the new system is disputed, and something will be, the question is what the previous record said, and reconstructing that from memory is how small discrepancies become long arguments.

The distinction that matters is between a frozen reference and a maintained parallel. A dated snapshot nobody edits is insurance. A sheet somebody is still updating means the migration has not happened, and it will keep not happening while the alternative exists.

Set the date on which the frozen copy stops being authoritative and say so explicitly, because otherwise it drifts into being the thing people check first. Two cycles is usually enough: by then the system has produced numbers that reconciled, and the confidence that matters has been built on output rather than on assurance.

A final note on what migration exposes. Most businesses discover during cleaning that their employee records were never the problem people assumed — the gaps are in joining documents, confirmation letters and asset issue records, none of which were ever collected properly in the first place. Migration surfaces that because it is the first time anyone has looked at every employee's file at once. Closing those gaps belongs upstream, in employee onboarding, and doing it alongside the migration means the new system starts complete rather than inheriting the same holes in a tidier format.