Implementing payroll software with reconciled migration, parallel runs and a rehearsed cutover

Implementation succeeds when the first live payroll is correct, authorised, reported and recoverable. Installing software or importing employees is only the beginning. Use a named owner, documented scope and controlled cutover.

Confirm scope and authority

Record the employer entities, PAYE schemes, employees, pay calendars, worker situations, deductions, pension arrangements and integrations moving to the system. Identify who approves data, payroll, submissions and payments.

HMRC's running payroll overview provides the standard sequence around payday and the following tax month. Map each step to the new system and a responsible person.

Prepare and protect data

Inventory source records, remove obsolete duplicates, validate mandatory fields and agree opening balances. Transfer through an approved secure route. Limit implementation access and retain an audit trail of imports and corrections.

Document personal-data roles, retention and deletion for temporary migration copies. Use synthetic records during early configuration and training.

Configure the tax-year context

Confirm product edition, tax year, PAYE references, pay schedules, statutory settings and applicable reporting. Check the exact product on HMRC's recognised software directory.

HMRC warns in its software guidance that mishandled payroll IDs during a change can duplicate records or affect the PAYE bill. Decide whether identifiers continue and handle any change indicator correctly for the circumstances.

Test workplace pensions

Configure the named scheme, contribution basis, tax-relief method, assessment and worker events. The Pensions Regulator's payroll process guidance recommends ensuring the software or outsourced process works with automatic enrolment.

Generate safe test files, confirm provider acceptance and reconcile contributions. Assign failed-file investigation and employee communication.

Run parallel payrolls

Process representative ordinary, starter, leaver, variable-pay and correction cases in the old and new systems. Reconcile gross pay, deductions, employer liabilities, net pay, pension contributions and reports. Investigate every difference rather than applying a blanket tolerance.

Keep the old process authoritative until named acceptance criteria are met. Prevent the test system from sending live reports or payments without explicit authority.

Rehearse cutover and failure

Prepare a dated cutover checklist, final data extract, approvals, support contacts and rollback decision. Test user access, submissions, acknowledgements, payslips, journals, pension exchange, backups and restoration.

During the first live cycles, increase review and record interventions. Confirm HMRC and pension outcomes, not only transmitted files. Keep employees informed through the employer's approved route.

Close implementation only after reconciliations, exceptions, access review, temporary-data disposal, documentation and handover are complete. Schedule a post-run review and tax-year readiness check. A fast go-live is not a success if unresolved differences are carried into the next payday.

Prepare people and communications

Train each role on its own tasks, permissions, evidence and escalation. Operators need realistic cases; approvers need reports and control points; administrators need access, backup and incident procedures. Confirm who answers employee questions without exposing records to unauthorised staff.

Tell affected employees about a changed payslip or self-service route through an approved employer communication. Provide accessible instructions and a way to report difficulty. Do not use the implementation notice as consent for unrelated marketing.

Stabilise after launch

For the first agreed runs, compare expected and actual headcount, gross-to-net totals, employer liabilities, pension amounts, reports and payments. Review failed logins, support requests and manual work. Preserve the evidence and name any accepted difference.

Restrict configuration change during the stabilisation window. Urgent fixes need review, testing, approval and a rollback path. Once results are stable, transfer open issues into normal ownership and confirm that implementation-only accounts and data copies have been removed. Measure whether the promised outcome was achieved before releasing the project team.