
Operations
Part of Payroll software operations and delivery 2027: a review framework
Payroll software go-live checklist: PAYE, pensions, data and rollback
A payroll software launch checklist for go-live: PAYE and RTI tests, pension files, UK GDPR and security, recovery, cutover deadlines and rollback.
This go-live checklist is for the team releasing a payroll product to its first employers. A payroll software launch gate decides whether your defined payroll or HR software version can support a specific customer safely. It is not a demonstration or a meeting where unresolved risks disappear into minutes. Give every gate an authorised owner who can stop release.
What to take away
- A launch review decides if a defined product version can safely support a specific customer.
- Every gate needs an authorised owner who can stop release before go-live.
- Record pass, fail, unknown or accepted risk for every item with evidence.
- A green technical dashboard cannot overrule an unresolved customer payroll difference.
- Close the launch phase only when unresolved issues have ordinary owners and the workflow is stable.
Customer and product scope
- Name the target role, employer model and payroll pattern.
- Record supported employees, frequencies, schemes and tax year.
- Put exclusions in sales, contract, onboarding and support material.
- Confirm the exact build, infrastructure and dependencies.
- Resolve every pilot difference or document authorised acceptance.
PAYE readiness
- Map applicable HMRC specifications and effective dates.
- Confirm HMRC recognition for the exact product against HMRC's recognised software list.
- Test FPS, EPS and other RTI submission types in scope.
- Pass ordinary, boundary, invalid, migration and correction tests.
- Preserve submission acknowledgements and errors.
- Assign monitoring for official change.
- Confirm the PAYE and National Insurance payment deadline (the 22nd of the next tax month for monthly payers, the 19th by cheque through the post) and the HMRC payment reference for the first live run.
For the 2025 to 2026 tax year, the relevant documents include the PAYE and National Insurance contributions specification and the expenses and benefits specification. Record the version and effective date you tested against, and check the product against HMRC's recognised software list. HMRC's PAYE developer collection is the primary index for current technical resources. Reopen it before the decision.
PAYE readiness checks
- Map HMRC specifications and effective dates
- Confirm recognition wording for product
- Pass ordinary, boundary, invalid, migration tests
- Preserve submission acknowledgements and errors
- Assign monitoring for official change
Pension readiness
- Test assessment, contributions and tax-relief configuration.
- Verify the named provider format or connection.
- Exercise worker requests, communications and records in scope.
- Confirm acceptance, rejection handling and reconciliation.
- Check The Pensions Regulator duties, including the automatic enrolment declaration of compliance and re-declaration.
- State employer and supplier responsibilities clearly.
Named connection types include NEST's CSV upload and API, The People's Pension's contribution file, and Smart Pension's API. Check the exact format the provider requires. The Pensions Regulator is the authority for pension duties: confirm the automatic enrolment declaration of compliance and any re-declaration, and that employer responsibilities are clear.
Data and security
- Approve controller, processor and sub-processor analysis under UK GDPR and the Data Protection Act 2018.
- Confirm the lawful basis, records of processing and DPIA where required.
- Verify access, authentication, logs, retention and export.
- Complete required security and privacy reviews.
- Check the security review against a named standard or certification such as Cyber Essentials, ISO 27001 or SOC 2.
- Close temporary accounts and remove test data.
- Confirm incident contacts, the ICO breach-reporting route and the 72-hour notification decision.
- Confirm ICO registration where applicable.
Operations and recovery
- Run a full backup restoration and verify payroll completeness.
- Rehearse failed import, dependency and submission scenarios.
- Prevent duplicate processing during retry.
- Staff support around the selected customers' pay schedules.
- Publish service status and escalation routes.
The NCSC's cloud security guidance provides official prompts for authentication, logs, joiners and leavers, backups and incident preparation. Use it alongside a named security standard or certification such as Cyber Essentials, ISO 27001 or SOC 2, and record which one the product claims.
Commercial and communication readiness
- Match order forms and claims to supported scope.
- Verify pricing, billing units, renewal and exit.
- Check data-processing and service commitments against operations.
- Train sales and support on limitations.
- Prepare customer and employee communications.
Cutover decision
Name the live authoritative system, approval time, rollback trigger, rollback owner and point after which reversal needs another plan. Confirm the PAYE and National Insurance payment deadline and the correct HMRC payment reference for the first live pay run. HMRC's FPS guidance makes reporting timing and correction material to the decision: send the FPS on or before the employees' payday, and pay HMRC the balance by the 22nd (or the 19th if paying by post).
A concrete rollback trigger is a live FPS not accepted by 17:00 two working days before payday. The reversal deadline can be the same time; after that, correct through an amended FPS and a written plan.
After launch, hold enhanced reviews over several payrolls. Check outcomes at HMRC and pension providers, corrections, access events, support work and customer understanding.
People and capacity
- Name payroll, product, engineering, quality, pensions, privacy and security owners.
- Confirm trained cover for every deadline-critical role.
- Verify access and escalation contacts before the launch window.
- Compare customer payroll schedules with support capacity.
- Run an incident exercise with actual decision-makers.
Evidence pack
- Store requirements, sources, tests, defects and approvals together.
- Record the product build and configuration under review.
- Link each marketing and contract promise to supporting evidence.
- Preserve pilot reconciliations and customer acceptance.
- Give volatile sources and controls a review date.
Worked example: test case FPS-07 submits a full payment submission for 25 employees with one starter and one leaver. Expected result is acceptance with no errors. Evidence entry: HMRC correlation ID, acceptance timestamp, and the test owner's sign-off date.
First-run monitoring
Track prepared, approved, transmitted, acknowledged, rejected, corrected and reconciled states separately. Watch for unusual access, duplicate action, pension mismatch, failed documents and support escalation. Restrict non-essential configuration changes while the service stabilises.
Hold a review immediately after each early payroll. Decide whether to continue, narrow, roll back or add controls. Document the decision and communicate material effects through the approved route.
Record when temporary launch access, heightened monitoring and project-only data copies will end. Confirm their removal rather than assuming normal operations inherited them safely.
Common questions
What must be decided at the cutover point?
Name the live authoritative system, approval time, rollback trigger, rollback owner and the point after which reversal needs another plan. Confirm the PAYE and National Insurance payment deadline and the correct HMRC payment reference for the first live pay run. HMRC's FPS guidance makes reporting timing and correction material to that decision, so record it before release.
How should early payrolls be monitored after launch?
Track prepared, approved, transmitted, acknowledged, rejected, corrected and reconciled states separately. Watch for unusual access, duplicate action, pension mismatch, failed documents and support escalation. Restrict non-essential configuration changes while the service stabilises, and hold a review after each early payroll.
What should the evidence pack contain?
Store requirements, sources, tests, defects and approvals together. Record the product build and configuration under review, and link each marketing and contract promise to supporting evidence. Preserve pilot reconciliations and customer acceptance, and give volatile sources and controls a review date.



