A go-live readiness checklist for HR software, and how to make a call you can defend

The go or no-go decision is often made in a meeting where everyone is tired, the date has been announced, and nobody wants to be the person who says no. A checklist agreed weeks earlier takes most of the pressure out of that meeting. The question changes from "do we feel ready" to "what does the list say".

What makes a checklist useful

• It is agreed early. Write it at the start of testing, when nobody has a reason to bend it.
• Each item is checkable. "Training done" is vague. "Managers and employees trained" with an attendance list behind it is checkable.
• Each item has an owner. One person who can say yes or no.
• Items are weighted. A late launch email and an untested payroll are different sizes of problem. The list should show that.
• Some items are hard stops. A few conditions should block go-live whatever the rest of the list says.

The checklist

This is a starting list for an HRIS and payroll rollout. The points add up to 100. Change the weights to fit your project, but do it before testing starts.

Item	Points	Evidence
UAT scripts passed by HR, Finance and a manager group	20	Signed test results for each script
Parallel payroll runs within tolerance	15	Variance for each run, signed by Finance
Employee data validated against legacy headcount and pay	15	Reconciliation of counts and totals
Integrations tested end to end	15	A real file received at the carrier and the ledger
Managers and employees trained	10	Attendance or completion records
Cutover and rollback plan approved	10	A written plan with a named approver
Launch communications sent	5	The sent messages
Hypercare owner, channel and hours confirmed	5	Names and a schedule
No open critical issues	5	The issue log

If you are rolling out across regions, add an item for regional privacy and works council sign-offs, and give it real weight.

Hard stops

A score on its own can mislead. You could reach 90 points with an open critical issue, because that item is only worth five. So treat two conditions as hard stops that block go-live by themselves:

1. Any open critical issue. Critical means it would pay someone wrongly, expose data to the wrong people, or stop a legally required process.
2. Any parallel payroll run outside tolerance. If the last run missed, you have not shown the system can pay people correctly. See how to work through a missed run.

Setting the threshold

Pick the score that means Go before you start scoring. Ninety out of 100 is a sensible bar. It lets you go live with a small item open, such as a final reminder email, and it stops you going live with a large one missing.

Write down what happens to the open items. "We went live at 92 with manager training for the night shift scheduled for day three" is a decision. Going live at 92 and never mentioning the gap is a risk nobody agreed to take.

Running the go or no-go meeting

1. Hold it early enough to act. A week before go-live gives you time to close a gap or to tell people about a new date. The night before gives you neither.
2. Invite the people who own the items. HR, Payroll or Finance, IT, the vendor lead and the sponsor.
3. Walk the list, item by item. The owner says done or not done and points to the evidence. No discussion of feelings until the list is finished.
4. Read out the hard stops. Open critical issues and payroll run results.
5. State the score and the call. Then ask the sponsor to confirm it.
6. Record it. The date, the score, the open items, and who made the decision.

If the answer is no-go

A no-go is the checklist doing its job. Handle it in a way that keeps trust.

• Name what blocked it. Specific items, each with an owner and a date.
• Set the next decision date. You do not need a new go-live date yet. You need the date you will next decide.
• Choose a safe new go-live. For payroll, switch at the start of a pay period. Avoid year-end and the weeks around open enrollment unless you have no choice.
• Tell people quickly. Employees and managers handle a delay far better than a wrong paycheck.
• Keep the old system running. Check contract end dates before you ever get to this meeting, so that a short delay is possible.

How to make the call defensible

Months later, someone may ask why you went live when you did, or why you delayed. You can answer if four things are true:

• The criteria were written before testing began.
• Each item was marked by a named person on a known date.
• The hard stops were checked from the issue log and the payroll results, without anyone's judgment in between.
• The decision and its open items were written down at the time.

None of this needs special software. A shared document can do it. The discipline is what matters.

Where HRjects fits

HRjects has this checklist built in. Each project has a go-live readiness workspace with weighted items that produce a percentage and a Go or No-go. Go needs 90% or more, plus two automatic checks that nobody can tick by hand: no open critical issues in the issue log, and every parallel payroll run within tolerance. The project's activity log records who ticked what and when. You can change the items and their points to suit your project. The steps are in this help article, or you can try it on a free project.