Do not go live cold. Reproduce a month you have already paid in the new system, compare it line by line against the old register, and investigate every difference until you can explain it. Differences are more often policy interpretations than defects. Sign the comparison off, then cut over on the next cycle.
A parallel run means processing a period you have already closed in the old system, in the new one, and comparing the two. It is the only test with a known-correct answer to compare against, because the earlier month has already been paid, queried and accepted by employees. A sandbox with sample data proves the software works; a parallel run proves it works for your policies, your structures and your people. Pick a period containing real awkwardness, ideally one with a joiner, a leaver, a revision and an off-cycle payment in it, rather than the quietest month of the year. New [payroll software](/payroll-software) will reproduce a simple month easily, which tells you almost nothing.
Employee master data, salary structures, effective dates, year-to-date figures, statutory identifiers and registrations, outstanding loan and advance balances, leave balances where they affect pay, and bank details. Year-to-date figures are the ones teams underestimate, because several computations depend on what has already been paid and deducted during the year, and a run without them will differ from the old system for reasons that have nothing to do with the software. Load from an export of your [employee database](/employee-database-software) rather than retyping, and reconcile the count and the totals of what you loaded before processing anything at all.
At employee level and component level, never on the net total. Two runs can agree on the total and disagree on every line inside it, which is worse than an obvious mismatch because it surfaces months later. Build a comparison listing each employee, each component, the old value, the new value and the difference, then sort by the size of the difference and work down. Agree in advance what counts as a match, since rounding at component level can produce trivial differences not worth chasing individually but still worth understanding. Keep the comparison file afterwards; it is the evidence behind your sign-off.
Because the old process contained decisions nobody wrote down. A proration basis chosen years ago, a rounding convention, the order in which deductions are applied, an allowance somebody adjusted by hand each month, a component treated one way for one grade and differently for another. The new system applies whatever rule you configured, consistently, and the difference exposes the undocumented practice. When you find one, the useful question is not which system is right but which behaviour you intend to keep, and whether the old one was actually correct. Take any difference involving a statutory treatment to a qualified advisor before deciding which version to standardise on.
The person who will own payroll in the new system, not the project manager and not the vendor. What they sign is a statement that every remaining difference has an explanation they accept, and that those explanations are recorded. Set the bar explicitly at nil unexplained differences rather than at a tolerance or a feeling. If a difference cannot be explained, it stays open and go-live waits, because an unexplained difference in a test run becomes an unexplained difference on a real payslip. Circulate the comparison and the explanations to finance as well, since they meet the same numbers in the ledger.
The rehearsal ends and the deadlines are real. Move the cut-off earlier than usual for the first live period to buy review time, tell input owners why, and keep the old system readable rather than switching it off on go-live day. Have the vendor's implementation contact available on the run day itself instead of routed through a support queue, and agree beforehand what counts as an escalation. Tell employees the payslip will look different and where to raise a query, because a changed layout generates questions even when every figure is right. Publishing through an [employee self-service portal](/employee-self-service-portal) helps, provided people have their login before payday rather than on it.
Late inputs, because owners are still on the old rhythm. Missing bank details for recent joiners. A component nobody considered because it did not occur in the parallel period, such as a quarterly incentive or an annual reimbursement. Access problems for employees on payday. None of these are software failures, and all are containable if the response is planned before it is needed. Agree the correction path in advance: what gets fixed through an off-cycle payment, what waits for the next run, who tells the employee, who records the change. Handle the first correction properly and the team will trust the system; handle it as an untracked edit and you have started the new system with the old habits.
Pitch N Hire is an applicant tracking system built for recruiters and hiring teams. If this answer described something you want to run properly, the ATS is where it lives.
Free for 1 user · No credit card · Talk to a real hiring expert
Get a personalized walkthrough of Pitch N Hire on your own roles and workflow. No slides, no obligation.
Prefer to talk? Book a demo · Talk to sales · View pricing
Free 1-user plan · No credit card · Talk to a real hiring expert
See your true cost-per-hire and how much Pitch N Hire could save you — our free Recruitment ROI Calculator gives you the numbers in under a minute. No signup required.
Open the free ROI calculatorPrefer a tailored walkthrough on your real roles? Drop your work email:
★ Free 1-user plan · No spam · Talk to a real hiring expert
