An HR system migration is safe when you can prove three things before go-live: payroll comes out the same, the records you must keep are still retrievable, and every system that reads HR data still gets it. Most HR migration problems come from skipping one of those checks, not from the new software. Here is how we approach each one, plus the access and cutover steps that hold it together.
Why are so many companies changing HR systems now?
Many mid-size and large companies run HR and payroll inside older ERP suites. SAP, for example, announced in February 2020 that mainstream maintenance for core SAP Business Suite 7 applications runs until the end of 2027, with optional extended maintenance to the end of 2030 at an added premium. Companies on those platforms are deciding whether to move HR to a cloud suite such as SAP SuccessFactors, to another vendor or to a newer on-premise release.
Smaller companies face the same choice when they outgrow a payroll-only tool or a set of spreadsheets. Whatever the trigger, the migration risks are the same. The checks below apply whether you are moving from SAP, from a payroll provider or from spreadsheets.
Which HR records do you need to keep after the switch?
Start with retention, because it decides what has to move and what can be archived. US federal rules set minimums. The Department of Labor's FLSA recordkeeping fact sheet says employers must preserve payroll records for at least three years, and keep the records that wage computations are based on for two years. EEOC rules at 29 CFR 1602.14 require personnel and employment records to be kept for one year from the date the record was made or the personnel action, whichever is later.
State laws, union agreements and benefit plans often add longer periods, so confirm the full list with counsel or your HR compliance lead. Then decide, record type by record type, where each one goes:
- Migrate into the new system: active employees, current pay, open leave balances.
- Archive in a searchable, read-only store: terminated employees and pay history the new system does not need.
- Keep the old system read-only for a defined period, if archiving is not practical.
Write down who can retrieve archived records and how fast. An archive nobody can search does not do its job.
How do you prove payroll is right before go-live?
Payroll is the part employees notice first. The standard control is a parallel run: process at least one full pay cycle in both the old and the new system with the same inputs, then compare the results employee by employee.
Compare gross pay, each deduction, employer taxes, net pay and year-to-date totals. Investigate every difference, even small ones. A few cents on one person can point to a rounding or tax rule that affects hundreds. We suggest a test cycle that includes overtime, a new hire, a termination and a mid-period pay change, because those are the cases configuration most often misses.
Set a pass rule before you start, such as zero unexplained differences, and do not go live until you meet it. Our guide to CRM migration reconciliation applies the same idea to customer data: reconcile the work, not just the record count.
Which integrations break when the HR system changes?
HR data feeds more systems than most teams realize. Typical connections include:
- The payroll provider and the general ledger.
- Benefits carriers and retirement plan recordkeepers.
- Identity and access systems that create and remove user accounts.
- Time and attendance, scheduling and expense tools.
- Reporting and data warehouse jobs.
List every feed, its format, how often it runs and who owns it on each side. Then test each one with real records in a test environment before cutover. Give extra attention to account removal. If the new HR system does not trigger it for leavers, former employees can keep access to company systems. Our article on partner API acceptance tests covers how to test these handoffs, including failures and retries.
Who should have access to HR data in the new system?
HR systems hold pay, bank details, tax forms and sometimes leave records. A migration is the right moment to rebuild access from the ground up rather than copy old roles. Map each role to the data it needs: managers see their own team, payroll sees pay, HR partners see the groups they support. Remove broad admin rights that were handed out "temporarily" in the old system. Turn on audit logs and decide who reviews them.
Protect the migration itself as well. Extract files, test copies and mapping spreadsheets hold the same sensitive data as production. Keep them in a restricted location and delete them on a set date after go-live.
What does a safe HR cutover plan look like?
- Freeze configuration changes in the old system ahead of cutover.
- Complete at least one parallel payroll run that meets your pass rule.
- Test every integration with real records, including account removal.
- Confirm archived records can be found and opened.
- Load final balances, such as leave and year-to-date pay, and reconcile them.
- Keep a rollback plan, and keep the old system read-only until the first live payroll is confirmed.
Before you retire the old platform, back up its database and prove that backup restores. Our guide to database restore testing shows how.
Frequently asked questions
It depends on headcount, pay complexity and the number of integrations. Plan around pay cycles: leave time for at least one full parallel payroll run and for fixing what it finds, then go live at the start of a pay period.
It means processing the same pay period in both the old and new systems with the same inputs, then comparing gross pay, deductions, taxes and net pay employee by employee before go-live.
No. Migrate what the new system needs to operate and archive the rest in a searchable, read-only store that meets your retention rules. Federal minimums include three years for payroll records under the FLSA.
Keep it read-only until the first live payroll is confirmed and the archives are verified. Then back it up, prove the backup restores, and retire it on a set date.
Sources
- SAP News: SAP extends innovation commitment for SAP S/4HANA, provides clarity on SAP Business Suite 7 (February 4, 2020)
- U.S. Department of Labor: Fact Sheet #21, Recordkeeping Requirements under the FLSA
- eCFR: 29 CFR 1602.14, Preservation of records made or kept
Plan your HR system migration with us
Tell us which HR, payroll and finance systems you run today. We will map your data and integrations, plan the parallel run and build the connections the new system needs through our API integration services.
