Switching HR software: the export test, the parallel month and the cut-over checklist
Staying with the wrong system because moving feels risky is how companies end up paying for software everyone works around. The move itself is a six-week project with three known hazards - all avoidable if you plan for them.
Export everything early, run old and new side by side for one payroll cycle, and cut over at a quiet point in your leave year with a written list. The three hazards: data you cannot get out of the old system, balances that disagree between systems, and compliance dates that fall between the two. Each has a section below.
Should you switch at all?
Switching costs a month of someone's attention, so switch for structural reasons: a pricing model that has turned against you (per-module fees stacking up, a tier jump forced by one feature), data you cannot get out or reports you cannot build, or a system your managers quietly route around with spreadsheets - the surest sign of all, because you are paying for software and doing the work by hand. Do not switch because a demo looked shinier; demos always do. If you are re-choosing, do it properly - our buyer's guide and requirements checklist are the method, and this time weight the exit questions, because you now know what being stuck feels like.
The switch at a glance: a six-to-eight week plan
| Weeks | Work | Exit test |
|---|---|---|
| 1–2 | Full export from the old system; check completeness (documents especially); clean the data | Every person's file complete in the export |
| 3–4 | Load the new system; reconcile headcount, balances and compliance dates against the export | Balances agree person by person |
| 5–8 | Parallel run through one full payroll cycle; managers use the new system with real requests | Payroll export from new system matches old |
| Cut-over | Work the checklist below; old system goes read-only, not deleted | Everyone logged in; every register complete |
| +90 days | Survive a quarter and one leave-year event, export a final archive, cancel the old system | Archive stored access-controlled |
Getting your data out: the export test
Do the export first, not last - it is both your migration source and your leverage. Ask the incumbent for a full export and look at what actually arrives: people and contract data, leave history and balances, sickness records, documents (contracts, right-to-work evidence), and anything sector-critical like training or DBS records. Three things to watch: documents are the most commonly incomplete part of an export - check a sample person's file end to end; formats matter less than completeness, since a messy CSV can be cleaned but a missing field cannot; and timing - export while your subscription is healthy, because an exit-week export request tests the vendor's goodwill at exactly the wrong moment. You learn a lot about a vendor at export time; it is the moment their incentives stop pointing at you.
One thing the export test is not is a legal right you can invoke. Data portability under the UK GDPR belongs to the individual, not to you as the employer, and the ICO is explicit that it only applies to information an individual has provided to a controller. Your employees can ask for their own data; you cannot use their right to prise your HR database out of a vendor who would rather you stayed. Getting a complete export is a contract question, which is why it belongs in the contract before you sign, and why the time to test it is while the subscription is healthy rather than in your notice period.
The parallel-run month
Load the new system, then run both for one full payroll cycle. Approvals happen in the old system (it is still the system of record); the same events are mirrored into the new one, and at month end you reconcile: headcount matches, leave balances match person by person, the payroll export from the new system agrees with what the old one produced. Every discrepancy found in the parallel month is a data-cleaning task; the same discrepancy found after cut-over is a payroll error with a person attached. This is also the month to let managers try the new system with real requests - training against live data beats any walkthrough.
The cut-over checklist
- Leave balances as at the switch date - agreed, person by person, including carry-over and TOIL. This is the number employees will check first.
- Open items - pending leave requests, in-flight expenses, unfinished onboarding: close them in the old system or re-raise them in the new one, but decide item by item, in writing.
- Compliance dates - right-to-work expiries, probation ends, training renewals, DBS renewals if you track them: confirm each register is complete in the new system before the old reminders switch off. A date that falls between systems does not chase itself.
- Documents - spot-check migrated files against your export archive; verify the sensitive ones (contracts, RTW evidence) opened correctly rather than trusting the file count.
- Payroll and integrations - point the payroll export at the new system and tell your accountant or bureau the format is changing before they discover it.
- Access - everyone can log in before day one, managers know where approvals now live, and the old system goes read-only (not deleted) on the switch date.
Telling the team
One honest note beats a campaign: what is changing, the date, the one thing everyone must do (log in, check your balance, tell HR if it looks wrong), and why the company is moving - people co-operate with a reason more than an announcement. Asking everyone to verify their own balance in week one is not an admission of doubt; it is a hundred free auditors, and the questions it surfaces are the migration bugs you want found in week one rather than at Christmas.
The first 90 days: actually leave
Keep the old system read-only until you have survived one quarter and one leave-year event (a carry-over, a bank-holiday calculation), then export a final archive, store it access-controlled - retention obligations on records like right-to-work evidence outlive the software they were recorded in - and cancel. The failure mode is running both systems forever "just in case": you pay twice and nobody trusts either. And hold the new vendor to the standard that made you switch: if the move has not made the Monday-morning admin visibly lighter within a quarter, say so to them - a vendor worth staying with will want to know.
Leaving the old system switched on is itself a retention decision, and it is the one people forget to make: a decommissioned system still holding a full copy of everyone's records is still processing them. There is no fixed period to point at. The ICO's guidance is to review your records periodically and delete anything you no longer need, keeping only what specific legislation requires you to keep for a set time. So put a review date on the final archive the day you create it, and write down which obligation each part of it is being kept for - otherwise "we kept everything, just in case" quietly becomes your retention policy.
Frequently asked questions
How long does switching HR software take?
For a company of 20 to 150 people, plan six to eight weeks end to end: a week or two to export and clean your data, a couple of weeks to load and check it in the new system, one full payroll cycle running both systems in parallel, and a clean cut-over. The parallel month is the part people skip and regret.
When in the year should we switch?
At a quiet point in your leave year, after payroll has run and before a request surge - for many UK companies that means early autumn or the start of the leave year itself, and never the weeks before Christmas requests land. Switching at leave-year start makes balance carry-over arithmetic much simpler.
Will the new vendor migrate our data for us?
Ask - practice varies from CSV imports you run yourself to a managed migration, sometimes at extra cost. Whoever does the loading, the checking is yours: reconcile headcount, leave balances and key dates against the old system before anyone relies on the new one.
Do we lose our history when we switch?
You should not - export everything from the old system before your access ends and keep the archive somewhere access-controlled, because right-to-work evidence and disciplinary records have retention obligations that outlive the software they were recorded in. What you load into the new system can be slimmer: current records, balances and open items, with the archive held for reference.
Worth reading alongside
Keep reading: All 79 HR guides · 45 free templates · 27 calculators · Sector guides: agencies, software, consultancies, accountancy, architecture and engineering, marketing and PR, media, property · What shipped recently
Switching to CoDash
CSV imports for people, balances and history, a demo you can rehearse the whole move in first, and our own exit terms in writing - export at any time, including after you stop paying. We built the door out because we ask every vendor for one.