The parallel payroll run, step by step

Every migration plan on this site names the parallel run as the gating item. Nobody explains how to do one. This is how.

A parallel run processes a real pay period in both systems at once. The old system pays people and files, exactly as it always has. The new system calculates the same period from migrated data and pays nobody. Then you compare the two, employee by employee, and find out whether the configuration you have been building for six weeks produces the right number.

It is the only test that exercises the whole chain: migrated data, tax setup, benefit deductions, pay rules and the calculation engine, all at once, against a known answer.

---

When to schedule it

Work backward from the cutover date, not forward from today.

The parallel run needs to sit two pay periods before go-live. The first period is the run itself. The second is the room to fix what it finds and re-run if the variances do not close. Teams that schedule the parallel run into the period immediately before cutover have given themselves a test with no time to act on the result, which is a rehearsal, not a control.

Pick a period that looks like a normal one. A period containing your annual comp cycle, a bonus run or an open-enrollment change will surface differences that tell you nothing about steady state.

---

What to freeze while it runs

The comparison only means something if both systems are working from the same inputs. For the duration of the run:

• No configuration changes in the new system after the data snapshot is taken.
• Employee changes go into the old system first, then get mirrored into the new one with the same effective date.
• New hires and terminations in the period are in scope. Do not exclude them, because they are where date logic breaks.

Write down the snapshot time. Half the unexplained variances in a first parallel run turn out to be a change that landed in one system and not the other.

---

The four reconciliations

Run them in this order. Each one depends on the one above it being clean, so a gross-pay mismatch will produce tax and net mismatches that are not separate problems.

Compare	Source in the old system	Source in the new system	A mismatch usually means
Gross by employee	Payroll register for the period	Payroll register, same period	Rate, salary effective date, pay schedule or hours mapping
Employee deductions	Deduction register	Deduction register	Benefit plan mapping, deduction effective dates, arrears handling
Employer taxes and liabilities	Tax liability report	Tax liability report	A missing jurisdiction, an SUI rate not carried across, or a registration that has not been completed
Net pay	Net pay register	Net pay register	Anything above, or a supplemental tax method set differently

Reconcile at the employee level, not in total. Totals net out. Two employees wrong by the same amount in opposite directions produce a variance of zero and a payroll that is wrong twice.

Then reconcile year-to-date balances separately. YTD is not part of the period calculation, but it drives tax caps, benefit limits and every W-2 at the end of the year, and a YTD migration cut at the wrong date is invisible until it is not.

---

Which variances are benign

Some differences are correct. Deciding which in advance stops the run turning into an argument.

Expected, document and move on: rounding at the cent level on percentage-based deductions, and differences produced by a change you knowingly made as part of the migration, such as a corrected work location or a benefit plan that was mapped to the right code for the first time.

Not acceptable, and the cutover does not proceed until each is explained: any difference in taxable wages, any employee whose net pay differs by an amount nobody can account for, any missing employee, and any tax jurisdiction that appears in one system and not the other.

The standard is explanation, not size. A variance of eleven dollars that nobody can trace is worse than a variance of four hundred that you can point at a specific corrected deduction.

---

Who signs it off

Three people, named before the run starts:

• Whoever owns payroll operationally, on the reconciliation itself.
• Finance, on the total employer cost for the period, because that number lands in the accrual.
• The implementation owner, on the decision to proceed to cutover or to run the period again.

One signature is not a control. Payroll is the one system where the person who built the configuration should not be the only person who approves it.

---

When the parallel fails

Failing a parallel run is the run working. The cost of finding a tax registration gap in a test is two weeks of schedule. The cost of finding it in a live cycle is amended filings, penalties and a conversation with every affected employee.

If the variances do not close, move the cutover. Do not cut over on a plan to fix it afterwards. The one condition worth protecting is that nobody's first real payroll in the new system is also its first test.

---

The run on one page

1. Pick a normal pay period, two periods before cutover.
2. Snapshot the data, freeze configuration, log the time.
3. Process the period in the old system as usual. It funds and files.
4. Process the same period in the new system. It transmits nothing.
5. Reconcile gross, then deductions, then employer liabilities, then net, at employee level.
6. Reconcile YTD balances separately.
7. Explain every variance, or do not proceed.
8. Three named sign-offs.
9. Re-run if anything is unexplained.

---

If you want the run designed against your own pay calendar and registrations, book a 20-minute call.