Most of an employee file moves between HR systems without much trouble. What goes missing is the history that was never stored as a field: the audit trail of who changed what, the approvals behind past decisions, leave balances in the middle of a cycle, half-finished appraisals, and every value the old platform calculated rather than kept. Plan the migration around that list and the rest is data entry with a reconciliation step.
Most migration checklists that rank are published by HR platforms, the one you are moving to included. This one is published by an HR platform too. The section below on what does not survive is the part that costs a vendor something to write, so check it against your own export rather than taking anyone's word for it.
What comes across cleanly
People and their jobs. Current pay. Salary history where the old system exports it with effective dates. Documents as files. Org structure. Leave policies, rebuilt as configuration rather than imported.
These arrive as tables. The work is mapping columns, deciding what to do with the blanks, and agreeing which system is right when two disagree.
What does not survive, and what to do about it
| What is lost | Why | What to do instead |
|---|---|---|
| The change log | An audit trail is tied to the data model that produced it and rarely exports as an importable object | Export it as a file, keep it as an archive record with a retention date, note where it lives |
| Leave balances mid-cycle | A balance is a calculation from accrual rules, carryover caps and manual adjustments the new system never ran | Import each balance as a dated opening adjustment and reconcile per person |
| Historic approvals | Who approved the 2024 rise usually lives in a workflow record, not on the salary row | Export approvals as a report and attach it to the archive |
| In-flight cycles | A half-written appraisal has no stable shape to map to | Close the cycle in the old system, or restart it in the new one |
| Derived values | Tenure bands, service length, rating scales that do not map one to one | Recompute from start dates and raw ratings after import |
| Permissions | Role names look similar and mean different things | Rebuild from your access policy, never map one to one |
| Document metadata | Files move, but expiry windows, reminder thresholds and acknowledgement records often do not | Re-apply the schedule at import, and re-collect acknowledgements if the policy changed |
| Identifier coverage | The old system tolerated blanks nobody reported on | Treat the migration as the audit and fill the gaps before the first pay run |
Leave balances are what employees notice first after go-live. Someone's balance is out by two days, and reconstructing why means understanding an accrual rule in a system you have switched off. Migrating at the start of a leave year removes the problem rather than solving it.
The legal floor stays with the employer
Record-keeping duties do not transfer to the vendor. UK payroll records must be kept for three years from the end of the tax year they relate to, and HMRC may estimate what you owe and charge a penalty of up to £3,000 if full records are not kept. US employment tax records must be kept for at least four years after the fourth quarter return is filed, with six years for the records behind sick leave, family leave and retention credits.
A contract ending is not an exemption. Export everything before switch-off, including the material you are not importing, and put the export where your retention schedule can see it. Employee records: what to keep, where, and for how long covers how to write the periods.
One point on portability, because it gets quoted in the wrong direction. Article 20 gives the data subject the right to receive their personal data in a structured, commonly used and machine-readable format, where processing rests on consent or on a contract and is carried out by automated means, and to have it transmitted directly where that is technically feasible. That is an employee's right over their own data. Your own route to your organisation's data is commercial, which means the export clause and the export format in the vendor agreement deserve reading at signature, while both are still negotiable. Under Article 5(1)(d) the accuracy duty follows the data into the new system, so an import that silently truncates a field is your problem on the day it lands.
A sequence that holds up
Pick the date first and work backwards from a leave year, a tax year and a pay run, in that order of preference.
Inventory every object and give each an owner. Write the list of what will not move, circulate it, and have the HR lead sign it before the project starts. Migration disappointment is usually an expectation nobody wrote down.
Export twice: one extract for the import, one untouched copy for the archive. Import into a sandbox and reconcile counts per object, then reconcile values, because counts pass while data is quietly wrong. Total monthly payroll, total leave balance, and the number of people holding each statutory identifier will each catch a different mapping error.
Then run one full month in parallel: one pay run assembled from both systems and compared line by line, one leave cycle, one set of manager approvals. Switch after that comparison, and keep read-only access to the old platform until the archive has been verified.
Reconciliation checks worth running
Headcount by entity, against the old system and against the last payroll file. Documents per person, since file migrations lose attachments quietly. Salary rows per person, which catches history that flattened into a single current value. Contracted hours coverage, which decides whether pay equity reporting works after the move. Identifier coverage per country, named per person rather than counted. Leave balance per person as at the cutover date.
Each of those is a number you can compute on both sides. A migration signed off on the strength of a headcount match is signed off on the one check that always passes.
Two decisions to make at import
Choose the data residency region before the import, because a company's region here is write-once and changing it later is an export and an import rather than a setting. Ours is pinned per company to London or to Ashburn, Virginia, and the location is fixed in source rather than in an environment variable.
Decide what the first month of the new audit log has to prove. From day one it records the actor, who they acted on behalf of, and the values before and after every change, which is what makes the imported data distinguishable from everything entered since. The handoff from HR to payroll, step by step is the first process that tests it, in the first month after go-live. Our pricing has no base fee and no lock-in, which is worth checking on any platform before a migration rather than after one.
Answered here.
- What data actually moves when you switch HR systems?
- People, jobs, current pay, salary history where the old system exports it with effective dates, documents as files, and org structure. Those come out as tables and go in as tables. The parts that travel badly are the ones that were never fields: the audit trail, historic approvals, leave balances mid-cycle, in-flight review cycles, and anything the old platform calculated rather than stored.
- Will we lose our audit history?
- Usually the old system's change log does not import into the new one, because a log is tied to the data model that produced it. Export it as a file before switch-off and keep it as an archive record under its own retention period, alongside a note of where it lives. Your new log starts on day one of the new system and should be append-only from then.
- When is the best time to migrate an HR system?
- At the start of a leave year and, if you can line it up, near the start of a tax year. Both remove a reconciliation problem: a mid-year leave balance is a calculation from accrual rules and carryover caps that the new system did not run, and a mid-year payroll switch splits the statutory reporting for one entity across two sets of records.
- Who is responsible for keeping the old records after we switch?
- The employer. UK payroll records must be kept for three years from the end of the tax year they relate to, and US employment tax records for at least four years after the fourth quarter return is filed, whichever platform is holding them. Export before the contract ends and store the export where your retention schedule can see it.