Release assurance for a Unit4 payroll upgrade: scripts, parallel runs and defect triage

Most upgrade programmes write test scripts to the release. Bear Consulting Services writes them to the payroll. Its master script library covers pay and deduction elements, value references, absence, work schedules, learning and expenses, and is kept between engagements. Every release starts from a proven baseline, and scoping reduces to which scripts the release puts at risk.

Coverage runs by process area: position administration, applicant, starter, induction and probation, then absence, occupational health, leaver and contractual change, then student loans, voluntary deductions, variable transactions, back pay, overpayments, pensions auto-enrolment, payroll reversal, cost distribution and court orders. A release that touches the payroll engine touches most of that list.

The strategy precedes the library: entry and exit criteria, the phase structure for integrated system testing and user acceptance testing, and the templates that make evidence comparable across phases. One local government upgrade ran on exactly that structure: strategy and script libraries first, then phased execution across sixteen HR and payroll process areas. The upgrade acceptance programme in full.

A parallel run is only as good as the rules written before it starts.

Those rules belong in the test strategy: validation rules that define a match, reconciliation checkpoints where totals must agree, and rollback criteria that say in advance what result would stop the release.

Three design choices follow. The period first. A quiet month proves a quiet month, so choose one that carries the events the release touches: a pay award with back pay, a sickness case crossing from full pay to half pay, a court order, a leaver with a final calculation, an auto-enrolment assessment. Then the population, pay group by pay group, because a merged total can net two errors in opposite directions to zero. Then the expected answer: a known-correct value from the legacy calculation for every comparison, held separately and compared to the penny.

Beyond those three choices, every run needs a written statement of what it does not cover. Every run has a boundary, and the board must see it.

The lifecycle is the easy part: identification, triage, severity categorisation, assignment, fix verification and closure, tracked in the issue tracker or service desk the programme already runs.

Severity is the hard part. On a payroll release it follows what the defect touches: an employee's payment first, then a statutory submission, then a deduction owed to a third party, then a report.

Triage runs live, with the person who can reproduce the behaviour and the person who can read the configuration at the same screen. Tickets across a service desk turn a half-hour diagnosis into a fortnight. Retest scope is set at the point of fix: a payroll fix is a configuration change, and a change on a shared element can move a value on a population nobody was thinking about. Regression validation around each fix is how a release reaches go-live with no critical defects outstanding.

A release is not finished until its evidence pack is.

A usable pack holds five things. The agreed strategy. The execution record, script by script, with results and dates. The defect register with discovery and fix rates over time, because the trend tells a board more than any total. The residual position: what is open, at what severity, and which compensating control covers it for the first live cycles. A go or no-go recommendation with the reasoning attached.

Before the release, the pack gives the board something to decide against. Afterwards, the pack records why the decision was reasonable, still readable once those who ran the programme have moved on. Dated defect status reports through execution make it credible.

As HR and payroll lead consultant at an international organisation, Mircea Rogojan-Rush found payroll, absence, expenses and timesheets unproven, with no evidence base on which anyone could sign a go-live.

He built the assurance in the order above. Parallel runs compared new-system output against the legacy calculation for every pay group. A defect register, with resolution rates reported to the project board, kept the trend visible. The test completion evidence pack carried a quantified residual risk assessment into the decision.

The runs proved calculation parity across a payroll of over 2,500 employees, and the board took its go-live decision against the residual risk he had quantified. The case study in full.

• The Embedded Intelligence Method: test strategy, execution record and post-change validation as one evidence trail.
• Services: release assurance as a defined piece of work or embedded through the release, alongside the health check, the Unit4 X-Ray and PolicyAI.
• Proving a payroll of over 2,500 employees: the parallel run, the defect register and the evidence pack behind a go-live decision.