Payroll provider switch

Switching payroll providers is the HR project with the least room for error. If the first live run is wrong, every employee knows on payday. The work that prevents that is mostly testing, and testing is the part that gets squeezed. HRjects puts the payroll tests in the middle of the plan, where they are hard to skip.

Start from an HR template

Create a project from the Startup HRIS rollout template. It has a Payroll workstream, a Finance team, starter tasks such as documenting pay calendars and setting up pay codes, deductions and tax jurisdictions, and a "Payroll run" process map waiting to be filled in. If payroll is the only thing changing, remove the tasks and exit criteria that do not apply.

Map the payroll run before you configure

In Process maps, write the payroll run as it works today: how time is collected, who keys what, how deductions are checked, how the journal reaches accounting. Flag the steps with re-keying and manual checks as pain points. Then write the future state beside it. The differences are your configuration and integration requirements. Log each as a gap and turn it into a task with one click. There is a worked example in this article on process mapping.

Track parallel payroll runs

The Go-live readiness workspace includes a parallel payroll tracker. It starts with two runs.

1. Run the same pay period in the old and new systems and compare total net pay. You do this in your payroll systems.
2. Enter the net-pay variance as a percentage against the run in HRjects.
3. HRjects checks it against the tolerance, which is plus or minus 0.1% by default.

Add more runs if one misses. People with the Contributor role can record results, so Finance can enter them without a paid seat.

HRjects stores the percentage and nothing else. It does not do the comparison and it never holds pay data.

A go-live decision that depends on payroll

The readiness score cannot show Go until:

• the weighted checklist reaches 90% or more,
• every parallel payroll run has a result within tolerance, and
• no critical issue is open.

The last two are worked out automatically from the tracker and the issue log. The final phase gate also carries the exit criterion "Two parallel payroll runs within tolerance", and ticking it records who signed and when.

Log what the runs find

When a run misses, log each cause in Issues with a severity, the Payroll module and an owner. Anything that would pay people wrongly is Critical, and a Critical issue holds the project at No-go until it is resolved. Describe the problem without naming employees or quoting pay.

Keep the rest of the switch in view

• Integrations: the general ledger export and the benefits deduction feed each get tasks in the Integrations workstream.
• Cutover: the readiness checklist includes "Cutover and rollback plan approved".
• Hypercare: keep using the issue log through the first live runs.

Read more

Parallel payroll testing: how to run it and what to do when a run misses covers the method. This help article covers the steps in HRjects.