HR Software Migration: How to Switch HR Systems Without Losing Data
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Updated September 2026.
An HR software migration moves employee records, payroll history, and benefit data from one HRIS or payroll platform to another, without breaking a paycheck, a tax filing, or a benefits election. Two things make it harder than most software switches: the data is legally consequential, and the calendar is not yours to pick.
A CRM migration that drops a custom field is annoying. A payroll migration that loses year-to-date earnings, a tax withholding election, or a benefit deduction produces an incorrect paycheck, an incorrect W-2, and a compliance problem with your name on it. And you can't cut over whenever a project plan says you're ready: payroll runs on a fixed cycle, benefits run on a plan year, and tax filing runs on quarters. This guide is built around those two constraints.
Why HR migrations go wrong
Key Facts: HR software migration
- Roughly 80% of data migration projects overran budget or timeline, or were aborted outright, per Bloor Research's widely cited study.
- The average payroll error costs $291 to correct, and the average organization runs 15 corrections per pay period, per EY's December 2022 analysis.
- 1 in 6 companies EY surveyed had faced litigation tied to payroll errors, averaging $3,200 in direct costs and 29 hours of internal time apiece.
- Form I-9 must be kept three years after hire, or one year after termination, whichever is later, and that clock doesn't reset when you switch HR vendors.
Most HR migrations fail in a handful of predictable ways, none of which look like a CRM migration's failure modes.
| Failure mode | What happens | Why it's worse in HR |
|---|---|---|
| YTD earnings and withholding don't carry over exactly | Totals get zeroed, duplicated, or split | Feeds straight into W-2s |
| Accrual balances import, the rules don't | First accrual run quietly diverges | Nobody notices until a PTO balance is wrong |
| Benefit elections and dependents migrate incompletely | Wrong deduction, or coverage drops | Surfaces mid-plan-year, not at renewal |
| Cutover lands mid-quarter or during open enrollment | Filings and elections split across systems | Forces reconciliation instead of a clean handoff |
| Old-system access isn't revoked or preserved correctly | A departed admin keeps write access | Security gap and compliance gap at once |
| Documents don't migrate at all | Offers, policies, I-9s stay behind | Your retention clock doesn't stop with the vendor |
Treat each as its own workstream; none gets fixed as a side effect of a clean export.
What data actually has to move
| Data type | Imports cleanly | Manual or dropped | Note |
|---|---|---|---|
| Employee master records | Usually | Encrypted fields | Verify national ID and bank details survive export |
| Employment history and job changes | Partially | Full history often flattens | Ask if promotions import, or just current state |
| Compensation history | Partially | Prior pay changes | Most tools import the current rate only |
| YTD earnings and tax withholding | Depends on timing | Mid-year import is manual | Why the cutover calendar below matters most |
| PTO balances | Yes, as a number | The rules behind it | See the accrual section below |
| Benefit elections and dependents | Rarely | Usually needs a carrier file reload | Plan this with your broker, not just the HRIS |
| Documents (offers, policies, I-9s) | No | Almost always manual | Budget a separate document-transfer project |
| Performance history | Rarely | Usually dropped | Export an archive before you lose access |
| Org structure and reporting lines | Usually | Breaks on orphaned manager IDs | Clean up departed managers' references first |
If you haven't settled on a destination yet, how to choose HR software and HR software evaluation criteria are the right starting points first.
Accrual rules: the classic silent failure
Accrual balances migrate as a static number. The rule engine that produced it (rate, tenure tiers, caps, waiting periods, proration) is configuration, and configuration doesn't move the way data does. Everything looks fine at cutover because the starting balance is right. The problem shows up on the first accrual run after go-live, once the new system's rules generate a different number than the old one would have.
| Accrual rule to verify | What to check | What breaks if you skip it |
|---|---|---|
| Accrual method (per period, per hour, anniversary, front-loaded) | Engine replicates the exact method | Balances drift from the next run |
| Rate by tenure tier | Every tier boundary, not an average | Under- or over-accrual by tenure |
| Carryover cap and reset date | Cap plus the reset trigger | Balances quietly exceed the old cap |
| Waiting period before accrual starts | Hires credited on schedule | New-hire balances wrong from day one |
| Negative balance or borrowing rules | Whether and how far employees can go negative | Payroll blocks or allows requests wrongly |
| Proration for part-time or mid-period changes | Formula matches, not the full-time rate | Part-timers and recent hires notice first |
Run the first post-cutover accrual cycle in parallel with the old system's math and compare every employee line by line. It's the same discipline as the parallel payroll run below, applied to one rule set that's easy to overlook because the balance looks fine right up until it doesn't.
The cutover calendar: pick a date payroll won't fight you on
Payroll runs on a fixed cycle, benefits on a plan year, and tax filing on quarters. Your cutover date has to respect all three.
| Window | Why it works, or doesn't | What it costs you |
|---|---|---|
| Start of a new tax year (January 1 in the US) | Every YTD field starts at zero | Vendors' busiest slot; book months ahead |
| Start of a fiscal quarter (not January 1) | Quarterly filings start clean | Mid-year YTD balances still carry forward |
| Mid-month or mid-quarter | Sometimes unavoidable on a contract end date | A full YTD import for every employee |
| During benefits open enrollment | Never | Elections and carrier files already in motion |
If you can't hit a clean boundary, plan the YTD import as its own workstream with its own validation step.
Records retention: what you keep after you leave the old system
Leaving a vendor doesn't end your retention obligations. Export a complete, standalone archive before decommissioning.
| Record type | Minimum retention | Governing rule | Note |
|---|---|---|---|
| Payroll records (rate, hours, deductions) | 3 years | FLSA recordkeeping, U.S. Department of Labor | Timecards only need 2 years; ADEA sets the same 3-year floor |
| Form I-9 | 3 years after hire, or 1 year after termination, whichever is later | USCIS Handbook for Employers | Calculated per employee, not one date |
| Employment tax records | At least 4 years after the tax is due or paid | IRS employment tax recordkeeping | Covers W-4s, 941/940 returns, W-2 copies |
| Personnel and employment action records | 1 year from the date of the record or action | EEOC recordkeeping requirements | Extend to case closure if charged |
These are US federal floors, not a ceiling; state and non-US rules often run longer. Confirm actual periods with counsel before finalizing a decommission date.
Access, permissions, and offboarding the old system
Decide who keeps read-only access after cutover, and for how long, before the first audit request comes in. Downgrade the payroll or HRIS super-user to read-only the day the new system goes live; don't leave old credentials active indefinitely. Revoke access immediately for any admin who leaves mid-migration, no exceptions. Give finance and auditors read-only access to an exported archive, not the live vendor system, through your retention period, and lock employee self-service to a view-only pay stub and tax form archive once the new platform's self-service works.
A step-by-step HR migration plan
| Phase | Owner | Typical duration | Key output |
|---|---|---|---|
| 1. Audit and scope | HR or payroll lead | 1-2 weeks | Record counts, spec, go/no-go criteria |
| 2. Map your fields | HRIS admin and payroll | 1-2 weeks | Field-mapping worksheet |
| 3. Clean and dedupe | HR operations | 1-2 weeks | Deduplicated, standardized export |
| 4. Choose your migration method | HR/payroll lead, procurement | Days | Signed SOW or import plan |
| 5. Sandbox test | HRIS admin and IT | 1-2 weeks | Sandbox validation report |
| 6. Parallel payroll run | Payroll lead | One full pay cycle (2-4 weeks) | Reconciled to the cent, sign-off |
| 7. Cutover | HR or payroll lead | 1-3 days | Go-live on a tax-year or quarter boundary |
| 8. Validate | HR, payroll, auditors | About 1 week | Signed validation checklist |
| 9. Decommission | IT or HRIS admin | 30-90 days after cutover | Archived export, old system closed |
Phase 1: Audit and scope. Pull headcount and record counts, sample records in a spreadsheet, and set go/no-go criteria and your cutover window first.
Phase 2: Map your fields. Build a field-mapping worksheet, with extra scrutiny on the fields least likely to match cleanly:
| Source field | Target field | Note |
|---|---|---|
| National ID / SSN | Same, encrypted | Confirm the export never exposes it in plain text |
| Tax filing status / allowances | Equivalent withholding fields | Rarely one-to-one; verify with a test paycheck |
| Direct deposit details | Same | Re-verify rather than trust the import |
| Benefit plan codes | Target plan codes | Usually needs a manual crosswalk with your carrier |
Phase 3: Clean and dedupe. Merge duplicates (a rehire re-added as a new profile is the usual cause), standardize formats, and archive out-of-scope terminated employees.
Phase 4: Choose your migration method. See "Migration approaches" below. The SaaS vendor evaluation scorecard helps weigh a vendor-led implementation against a specialist partner.
Phase 5: Sandbox test. Confirm record counts, org structure, and benefit plan codes before touching production data. Still evaluating a destination? How to run a software trial covers structuring that.
Phase 6: Parallel payroll run. Covered below; the step with no CRM equivalent, and the one that decides whether cutover day is calm or chaos.
Phase 7: Cutover. Execute on your chosen boundary and lock the old system to read-only, or treat any gap as a delta migration.
Phase 8: Validate. Confirm record counts, spot-check key records, confirm every integration reconnected, and get sign-off from payroll, HR, and finance.
Phase 9: Decommission. Export a complete archive covering your retention obligations, run the old system read-only for one more pay cycle, then close it.
The parallel payroll run: the step with no CRM equivalent
A CRM migration doesn't have this step, and it's the biggest reason an HR migration carries more risk than almost any other software switch. Run at least one full payroll cycle in both systems side by side, on the same live data, and reconcile every output to the cent before anyone flips the switch.
| What to compare | Where to look | What a mismatch usually means |
|---|---|---|
| Gross pay per employee | Payroll register, both systems | A rate, hours, or overtime rule mismapped |
| Net pay per employee | Payroll register | A tax table or deduction-order difference |
| Federal, state, local tax withholding | Tax summary report | Filing status or a local jurisdiction dropped |
| Benefit and garnishment deductions | Deduction register | A plan code, order, or cap not rebuilt |
| Employer-side tax liability | Employer tax liability report | State unemployment rate setup is wrong |
| PTO accrual for the period | Accrual report | The rule, not the balance, is the culprit |
| General ledger mapping | GL export or journal entry | Cost center mapping is incomplete |
Get sign-off on this before cutover, not after. A mismatch caught here is a configuration fix; the same mismatch found after go-live is a payroll correction, and per EY's analysis those average $291 each.
Employee communication and self-service re-enrollment
This is the step that generates support tickets, not the migration itself. Employees care whether their paycheck looks right and whether they can log in, not how clean your field mapping is.
Announce the cutover date two to four weeks out, and be explicit that pay dates aren't changing even though the system is. A week before, send self-service setup steps and a named contact, since most platforms require a new login. Expect a spike in password-reset tickets and staff for it.
If the new platform doesn't automatically carry forward direct deposit, tax withholding, or benefit enrollment, say so and set a deadline to re-confirm each one. A missed re-confirmation on direct deposit is a missed paycheck.
Migration approaches at a glance
| Approach | How it works | Cost | Main risk |
|---|---|---|---|
| Vendor-led implementation | New platform's onboarding team runs it | Bundled or quoted per engagement | Depends on vendor experience with YTD and accrual rules |
| CSV / template import | You export and load it yourself | Free to low cost, paid in staff time | Silently dropped accrual rules and YTD data |
| API or integration partner | Specialist or engineers move data via both APIs | Thousands of dollars to a full agency fee | Lower data risk, needs technical lead time |
| Manual re-entry | HR staff key in data by hand | Internal labor only | Transcription error, no automated check |
How to decide: a migration decision framework
| If you need... | Then do this |
|---|---|
| Under 50 employees, standard fields, no complex accrual rules | CSV or template import |
| 50-250 employees, standard accrual rules, one or two carriers | Vendor-led implementation |
| Integrations (time tracking, ERP, carrier) that must reconnect | API or integration-partner migration |
| Tenure-tiered accrual rules, multiple pay groups, multi-state payroll | Vendor-led plus your own parallel-run reconciliation |
| Zero budget for outside help, under about 25 employees | Manual re-entry, accepting less historical detail |
| A hard compliance requirement (multi-state, union, regulated industry) | API-based migration with full audit logging; involve legal first |
If you're narrowing down a destination for a small team, how to choose HR software for small business covers what matters at that size.
What it actually costs
| Component | Typical range or note | Who pays it |
|---|---|---|
| Implementation or migration fee | Quoted per engagement, rarely published | Buyer, sometimes waived in negotiation |
| Overlap period (running both vendors) | One to two months of both subscriptions | Buyer; budget it explicitly |
| Internal hours (HR, payroll, IT, cleanup) | Several weeks across audit through parallel run | Buyer, as internal labor |
| Document migration (I-9s, policies) | Almost always manual | Buyer |
| Ongoing per-employee software cost | Varies by vendor and product line | Buyer, recurring |
A few vendors publish straight per-employee rates worth using as a planning anchor. BambooHR: Core $10, Pro $17, Elite $25/employee/month, flat rate from $250/month for 25 employees or fewer (BambooHR pricing). Deel: HR Core (HRIS) $5, US PEO $125, Employer of Record $599 per employee/month (Deel pricing); for an EOR or global payroll move, how to choose global payroll software covers that decision. Justworks: Payroll-only at $8/employee/month plus a $50 monthly base fee; its PEO and EOR rates aren't published (Justworks pricing).
Several shortlist regulars publish no rate at all. Rippling and HiBob route every quote through sales, and Workday's contracts are negotiated individually. Gusto publishes only Contractor Only ($35/month plus $6 per person); Simple, Plus, and Premium show no figure, so treat any number for those as unverified. How to choose payroll software pairs well with this guide.
Implementation fees are almost always quoted per engagement, depending on headcount, pay groups and states, and whether accrual rules and carrier files are in scope. Ask directly what the fee covers, whether it includes YTD and accrual-rule rebuilds, and what happens if the parallel run finds a discrepancy after the quote is signed.
Frequently asked questions
How long does an HR software migration take?
A small team (under 50 employees, one pay group) can finish in a few weeks. A mid-market migration (50-250 employees) with multi-state payroll and tiered accrual rules typically runs 8-16 weeks, including audit, sandbox testing, and a full parallel payroll cycle. Union agreements extend that further.
Can I migrate mid-year instead of waiting for a tax-year boundary?
Yes, but it costs a full YTD earnings and withholding import for every employee, plus roughly double the reconciliation work. A fiscal quarter start is next best if you can't wait for a tax year. Never schedule a cutover across open enrollment.
What happens to my PTO accrual rules during migration?
Balances migrate as a number, but the rules generating them (rate, tenure tiers, caps, proration) are configuration and rarely migrate automatically. Rebuild each rule explicitly, then run one accrual cycle in parallel and compare it line by line before trusting the new system.
How long do I have to keep records after I leave my old HR system?
US federal minimums run from 1 year for personnel action records to 4 years for employment tax records, with Form I-9 needing 3 years after hire or 1 year after termination, whichever is later. States often require longer. Confirm periods with counsel and export a complete archive first.
What's the biggest mistake teams make in an HR migration?
Skipping or shortening the parallel payroll run. It's the one step with no CRM equivalent, and the only way to catch a tax-table or accrual-rule error before it produces a real, incorrect paycheck. Teams that skip it regret it within the first pay cycle.
Get the migration right the first time
An HR migration succeeds or fails on parts that don't look like a data export: the accrual rule nobody rebuilt, the cutover that landed mid-enrollment, the admin access nobody revoked. Treat the parallel payroll run as the real gate, not a formality, and the cutover itself becomes the smallest part of it.
If you haven't locked in a destination platform yet, start with HR software evaluation criteria before planning a timeline around it.
Related reading
Head of Enterprise Solutions
On this page
- Why HR migrations go wrong
- What data actually has to move
- Accrual rules: the classic silent failure
- The cutover calendar: pick a date payroll won't fight you on
- Records retention: what you keep after you leave the old system
- Access, permissions, and offboarding the old system
- A step-by-step HR migration plan
- The parallel payroll run: the step with no CRM equivalent
- Employee communication and self-service re-enrollment
- Migration approaches at a glance
- How to decide: a migration decision framework
- What it actually costs
- Frequently asked questions
- How long does an HR software migration take?
- Can I migrate mid-year instead of waiting for a tax-year boundary?
- What happens to my PTO accrual rules during migration?
- How long do I have to keep records after I leave my old HR system?
- What's the biggest mistake teams make in an HR migration?
- Get the migration right the first time
- Related reading