What to ask before a Unit4 cloud upgrade or web client migration

The first question is the current generation and how many hops the move covers.

The line runs from Agresso Milestone 4 and Milestone 5 to Unit4 Business World 7.4 through 7.8, then Unit4 cloud 26.x. A single-version step inside 7.x and a jump from a milestone release into the cloud are different propositions. The measure is how much configuration was built against behaviour the target release changes quietly.

For each hop, ask which HR and payroll process areas change behaviour and which change only appearance. The first group needs proving from first principles, the second a regression pass. A plan that does not separate them over-tests and misses the date, or under-tests and finds defects after cutover.

Two artefacts decide a smart client to web client migration before user acceptance testing starts.

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 and, for each gap, an agreed alternative for the service that uses the screen. The second is landing page configuration per role, so a payroll officer signing in after cutover sees their work.

Ownership decides both: who holds the mapping and whether anyone has opened it since kick-off, and whether landing pages are configured before acceptance testing. Without configured landing pages, testers never see the interface real users get.

Coverage is the question a sponsor can answer without technical knowledge, and the best predictor of a bad cutover.

A serious upgrade carries a test script workbook per module in scope: asset management, general ledger, purchasing, project accounting, timesheets and expenses, HR and payroll. Under each sits individually referenced evidence.

Behind the workbooks sits a written test strategy covering user acceptance testing and its exit plan, built from standardised integrated system test and acceptance templates. Ask for the strategy first. Then ask which modules have no workbook, and why. Then ask who wrote the scripts: a consultant who knows what the release changes, or the service that will also execute them. Scripts written by the service test what users already know works.

Bad data goes through the upgrade unchanged, into a system nobody trusts yet.

Where a load or conversion is involved, three written controls precede the first load: validation rules defining a valid record, reconciliation checkpoints stating what must balance, and rollback criteria saying when the load is abandoned. A migration test strategy written alongside the migration strategy makes them enforceable.

For an upgrade, that means cleanse and defect remediation ahead of cutover. Ask which data conditions are known to be wrong today, which the upgrade will surface, and which are cleansed before the move or carried across to be cleaned later.

The last question asked belongs first: what else lands on the payroll before go-live.

Payroll year end and statutory patches sit outside the upgrade plan but use the same system, test environments and people. A mid-upgrade patch changes calculation behaviour beneath a script library written against the pre-patch build, and every recorded result becomes questionable. A year-end run colliding with an acceptance phase takes the payroll team out of testing when its judgement matters most.

Ask for one combined calendar: statutory patch windows, the year-end sequence with its own test plan, and the acceptance phases. Then ask which can move. Usually only the upgrade date can. That is cheaper to learn in advance.

In local government, a major-version upgrade put every HR and payroll process at risk of silent regression. The board wanted acceptance evidence before authorising the release.

The author was test manager: he wrote the acceptance strategy and built master payroll and HR script libraries for reuse. Execution ran in phases, from position administration, starter and probation through absence, occupational health, leaver and contractual change. He managed the defect lifecycle from triage and severity categorisation through fix verification to closure.

The board received dated defect status reports and a recommendation backed by the numbers, and accepted all sixteen process areas on recorded evidence.

Read the case in full on the case studies page.

Three routes, and none needs an email address to start.

• Run the free health check first. Twelve questions across the six areas the Unit4 X-Ray assesses, cloud readiness among them, scored on the page in about two minutes: the Unit4 HR and payroll health check.
• Get the five questions answered. The six areas and three deliverables are on the Unit4 X-Ray page, and the other routes, upgrade assurance and embedded delivery among them, on the services page.
• Read the engagement behind the worked example. The upgrade above is written up as upgrade acceptance across 16 HR and payroll process areas.