Ask a vendor what migrates and you get a file list. That is the wrong unit. What determines whether a migration goes cleanly is which of three categories each thing belongs to, and teams sort them after the export rather than before.
The three buckets
Moves as data. People, employment records, compensation, balances, payroll history. Structured, exportable, and loadable in a defined order.
Gets rebuilt. Approval chains, permission roles, workflows, notification rules, document templates, report definitions. These exist in every HRIS and transfer between none of them. They are logic, expressed in one vendor's model, and the new system expresses it differently.
Stays behind. Records with a retention or confidentiality reason to remain where they are, and records you have no business carrying into a fresh system at all.
The expensive mistake is putting bucket two in bucket one. A team plans a four-week migration on the assumption that approvals and permissions come across with the records, discovers in week three that both have to be designed from scratch, and now has a configuration project running inside a data project with no time allocated to it.
Bucket one: the load order
Order matters because each stage is a dependency for the next. Loading people before the org structure exists produces records with nothing to attach to, and every system will accept them.
| Stage | What loads | Depends on |
|---|---|---|
| 1 | Legal entities, work locations, tax jurisdictions | Nothing. This is the foundation |
| 2 | Departments, cost centers, reporting structure | Entities |
| 3 | People, employment dates, status | Structure existing to attach to |
| 4 | Jobs, compensation, effective-dated history | People |
| 5 | Benefit enrolments and deductions | People, comp, plan configuration |
| 6 | Time-off balances and accrual rules | People, policy configuration |
| 7 | Payroll history and year-to-date figures | Everything above |
Two stages are where migrations actually break.
Effective-dated history (stage 4). A compensation record is not a number, it is a number with a date range. Systems that flatten history to current state lose the ability to answer what someone earned in March, which is the question comp reviews and diligence both ask. Decide how much history you are carrying and confirm the target system stores it the same way.
Year-to-date figures (stage 7). These have to be cut as of the exact cutover boundary. A YTD figure taken from the wrong date does not fail on load. It fails at the tax cap, or at the W-2.
Bucket two: what has to be rebuilt
Budget real time for these. They are the reason a migration needs an implementation, not an import.
- Permission roles. Do not port the old model. Old permission structures grew by accident, and rebuilding is the one chance to fix that before an AI layer sits on top of it. The permission audit covers the method.
- Approval chains. Who approves time off, expenses, compensation changes, terminations, and what happens when that person is the requester.
- Workflows and notifications. Onboarding, offboarding, status changes. Rebuild the ones people rely on and drop the ones that fire into an inbox nobody reads.
- Document templates. Offer letters, contracts, policy acknowledgements, with the merge fields mapped to the new field names.
- Reports. Every recurring report someone actually opens. Headcount, turnover, comp, and whatever the board pack needs.
Bucket three: what stays behind
Two reasons a record does not travel.
Segregation. Federal rules require some categories to sit in separate confidential files: ADA accommodation records, FMLA medical certification, genetic information. Migrating them into general employee records because they were in the same folder recreates the problem in a new system. Confirm the handling with counsel rather than with the implementation team.
Retention. Terminated-employee records past their retention period, and duplicate copies of documents already held elsewhere. A migration is the cheapest moment to stop carrying them, and the only moment anyone looks.
Keep the old system in read-only access for a defined window after cutover rather than migrating everything defensively. Agree the window and the export format in writing before you cancel the contract, because access terms after cancellation are rarely what people assume.
Reconciling the load
Three counts, run after each stage rather than at the end:
- Record count. What left the old system against what arrived.
- Sum check. Total compensation, total balances, total YTD gross, compared to a report from the source.
- Spot check by exception. Not a random sample. Pick the awkward ones: an employee with a mid-year comp change, one in a second state, one on leave, one rehired, one part-time with a non-standard schedule.
The exceptions are where mapping errors live. A random sample of thirty ordinary salaried employees will pass every time and prove nothing.
On one page
- Sort everything into moves, rebuilds, stays.
- Load in dependency order. Foundation first, history last.
- Cut YTD at the cutover boundary, not the export date.
- Rebuild permissions rather than porting them.
- Reconcile counts, sums and exceptions at every stage.
- Keep read-only access to the old system, on agreed terms.
Then, and only then, the parallel payroll run tells you whether any of it was right.
If you want the buckets sorted against your current system before you commit to a date, book a 20-minute call.
Download this guide
Take the whole thing with you.
The whole guide as one PDF you can send to your team. We email it over.
One email, with the PDF attached. Nothing else.
Common questions
Do we migrate terminated employees?
Only those still inside your retention period, and only into records marked as terminated. A migration is the cheapest moment to stop carrying files you no longer need to hold, and the only moment anyone reviews them.
How far back should payroll history go?
Far enough to cover the current tax year in full, plus whatever your retention policy and any open audit require. Year-to-date figures are the part that has to be exact. Older history can often stay in read-only access to the old system.
Can we keep our existing permission structure?
You can, but rebuilding is usually the better call. Permission models grow by accident over years, and a migration is the one moment the structure gets designed on purpose rather than inherited.