What to ask before a Unit4 cloud upgrade or Web Client migration

The first question is the one most programme plans assume rather than answer: which generation are you actually on, and how many hops does this move cover.

The line runs from Agresso Milestone 4 and Milestone 5, through Unit4 Business World 7.4 to 7.8, and on into the Unit4 cloud 26.x generation. A single-version step inside the 7.x range is a different proposition from a move that crosses from a milestone release into the cloud generation, and the difference is not measured in downtime. It is measured in how much of your configuration was built against behaviour the target release changes quietly.

Ask the question in this form: for each hop, which HR and payroll process areas change behaviour, and which change only appearance. Anything in the first group needs proving from first principles. Anything in the second needs a regression pass and no more. A plan that does not separate the two will either over-test and miss the date, or under-test and find the defects after cut-over. Cloud-readiness posture is one of the six domains a structured diagnostic assesses, precisely because it is the one most often assumed rather than measured.

A smart client to web client migration is not a reskin, and the work that decides whether users accept it is done before user acceptance testing starts.

Two artefacts carry it. The first is a client-to-client mapping: every screen, menu path and routine in the smart client set against its web client equivalent, with the gaps named rather than discovered. The second is landing page configuration, done per role, so that a payroll officer signing in after cut-over sees the work in front of them rather than a menu tree to relearn.

The questions to ask are ownership questions. Who holds the mapping, and has anyone opened it since kick-off. Are landing pages configured before acceptance testing, so that testers exercise the interface real users will get, or after it, so that the interface is untested at the point it goes live. Where a screen has no web client equivalent, has an alternative been agreed with the service that uses it, or will it be invented during the first week of live running.

Coverage is the question a sponsor can answer without technical knowledge, and it is the one that most reliably predicts a bad cut-over.

A serious upgrade carries a test script workbook per module in scope. On a full estate that has meant twenty-two workbooks in practice, running from asset management and the general ledger through purchasing, project accounting, timesheets and expenses, and across HR and payroll. Under each sits individually referenced evidence: one upgrade programme produced more than thirty-five separately referenced test evidence documents.

Behind the workbooks sits a written test strategy, covering user acceptance testing and its exit plan, and built from standardised integrated system test and acceptance templates rather than from a blank page each time. Ask to see the strategy before you ask to see a plan on a page. Then ask two coverage questions. Which modules in scope have no workbook, and why. And who wrote the scripts: a specialist who knows what the release changes, or the service that will also be executing them, which produces scripts that test what users already know works.

Data that is wrong before the upgrade is wrong after it, except that afterwards it is wrong in a system nobody yet trusts.

Where any load or conversion is involved, the controls belong in writing before the first load runs, not after the first reconciliation fails: validation rules that define what a valid record is, reconciliation checkpoints that state what must balance and against what, and rollback criteria that say in advance when the load is abandoned rather than patched. A migration test strategy written alongside the migration strategy is what makes those three enforceable.

The upgrade-specific version of the same discipline is cleanse and defect remediation ahead of cut-over. Ask which data conditions are known to be wrong today, which of them the upgrade will surface rather than repair, and which are being cleansed before the move rather than carried across and cleaned later. The last category has a habit of becoming permanent.

The question that gets asked last and should be asked first: what else lands on the payroll between now and the go-live date.

Payroll year end and statutory patches are not upgrade work, but they occupy the same system, the same test environments and the same people. A patch applied mid-upgrade changes calculation behaviour underneath a script library that was written against the pre-patch build, and every result already recorded becomes questionable. A year-end run colliding with an acceptance phase takes the payroll team out of testing at exactly the point their judgement is most needed.

So ask for the combined calendar rather than the upgrade calendar: statutory patch windows, the year-end sequence and its own test plan, and the acceptance phases, on one line. Then ask which of them can move. Usually the upgrade date is the only one that can, and that is far cheaper to learn in advance.

In local government, an HR and payroll estate faced a major-version upgrade that put every process at risk of silent regression, with a board that wanted acceptance evidence before it would authorise the release.

The work was an acceptance strategy rather than a test plan: master payroll and HR script libraries built to be reused rather than discarded, phased execution across the full process set from position administration, starter and probation through absence, occupational health, leaver and contractual change, and a managed defect lifecycle from triage and severity categorisation through fix verification to closure.

All sixteen process areas were accepted on recorded evidence rather than on sampling, with defect status reported on a dated cadence and a data-driven recommendation put to the project board.

Read the case in full on the case studies page.

Three routes, in ascending order of commitment, and none of them requires an email address to start.

• Check your own posture first. Twelve questions across the six assessment domains, including cloud readiness, scored on the page in about two minutes: the Unit4 configuration health check.
• Get the questions answered on your own estate. The structured diagnostic, its six domains and its three deliverables are set out on the Unit4 X-Ray brief, and the wider routes, including upgrade assurance and embedded delivery, on services.
• Read the worked example. The local government upgrade above is written up as an upgrade acceptance programme across 16 HR and payroll process areas.