A go-live readiness checklist for a new agency system

Reference article · 10 min read

Use this checklist in the weeks before a cutover, when the question is whether to go live on the scheduled date or move it. It is written for the project manager and the department leads who will own the system after the vendor's implementation team steps back.

Work through it with the people who can produce the evidence. Record every item as yes, no, or not applicable, with the name of the person who answered and the date they answered. An item nobody can produce evidence for is a no.

The output is not a page of checkmarks. It is a short list of open items, each with an owner, a due date, and a decision about whether the item blocks go-live or can be carried into the first weeks of operation.

The system does what the agency agreed to buy

User acceptance testing is complete and signed by agency staff. Evidence: signed test scripts or a signed acceptance memo naming the processes that were tested. Vendor testing is not a substitute. If signatures are missing for a process, either run and sign that testing before the date or record the process as unverified in the go-no-go decision.
Every open defect has a severity and a written disposition. Evidence: a defect list showing, for each item, fix before go-live, fix by a named date, or accept. If any defect has no disposition, hold a triage session with the sponsor and the vendor before the go-no-go meeting rather than during the cutover.
Each business process has been run end to end at the volume expected on a normal day. Evidence: a test record showing the full path, from intake through the final output, payment, or filing, run in one sitting. If the full path has never been run that way, schedule the run before confirming the date; if it cannot be scheduled, record the process as untested and name who owns the risk.
Integrations have been tested against the systems they will connect to in production. Evidence: results showing real transactions with each connected system, including error handling and rejected records. Testing against a simulated endpoint does not confirm field mappings, error behavior, or throughput. If a partner system cannot be reached before go-live, write the manual fallback procedure and name the staff who will run it.
Security and accessibility reviews are complete, and findings are closed or accepted in writing. Accessibility requirements commonly reference the Web Content Accessibility Guidelines; federal rules under the Americans with Disabilities Act adopt WCAG 2.1 Level AA for state and local government web content and mobile applications, and Section 508 applies to federal agencies and is cited in some state and local contracts. Confirm which standard your contract names. If findings remain open, get written acceptance from the official accountable for the system, with a remediation date attached.

Data is ready to move

The full conversion has been run on a copy of production data and the elapsed time recorded. Evidence: a run log with start and end times for the complete data set. A partial run does not establish how long the full volume takes. If the recorded time does not fit inside the planned cutover window, widen the window, reduce what moves at cutover, or move the date.
Converted data reconciles with the source. Evidence: record counts by table or program area and control totals for financial and caseload figures, compared against the source and signed by someone who knows the data. If the numbers disagree, find the cause before go-live rather than adjusting the target to match.
Program staff have read converted records by hand. Evidence: a sample of cases those staff know well, checked field by field, with the reviewer named. If nobody has done this, schedule it now; count reconciliation does not catch values that landed in the wrong field.
The rule for records that will not convert is written and approved. Evidence: a disposition stating whether exceptions are corrected in the source, entered manually after go-live, or left in the legacy system, and who does that work. If no rule exists, settle it before the final conversion run, because the exception list grows once the cutover starts.
Retention and legacy access are settled. Evidence: the applicable records retention schedule, a decision on how long the legacy system or an export stays available, and the list of staff who keep read access. If this is unresolved, decommission nothing and raise it with the records officer or agency counsel before the date.

People are ready to use it on day one

Every role has been trained on the tasks it performs. Evidence: an attendance record checked against the roster of staff by role, not a count of sessions delivered. If a role or a group of staff was missed, add a session before go-live or plan supervised work for their first days.
Accounts and permissions are provisioned and tested by role. Evidence: a sign-in test for each role confirming the person can complete the required work and cannot reach what they should not. If accounts are not provisioned and tested, treat this as a blocker; staff cannot work on day one.
Desk references, forms, public instructions, and web pages describe the new system. Evidence: a list of materials that mention the system, each marked updated or not updated. If any still describe the old system, assign an owner and a date to each and decide which ones must be corrected before go-live.
The day one support path is staffed and published. Evidence: a named contact or channel, its hours, and a notice staff have already received. If staff cannot say who to call in the first hours, arrange floor support and a dedicated phone or chat channel before the date.
Frontline supervisors have used the system and have stated whether they support the date. Evidence: a yes or no from each supervisor, recorded in the go-no-go notes. If any supervisor says no, write down the specific reason, since it usually names a concrete gap, and decide whether that gap blocks the date.
External users have been told what changes and when. Evidence: the notice itself, the channels it went out on, and the date it was sent or published. If nothing has gone out, publish notice of new portals, new sign-in steps, or service interruptions before the change rather than after it.

The cutover itself is planned in detail

A written runbook lists tasks, owners, and clock times. Evidence: the document, covering the last hours of the old system through the first hours of the new one. If no runbook exists, write it before the go-no-go meeting; drafting it usually surfaces steps nobody had assigned.
The runbook has been rehearsed. Evidence: a dry run in a test environment with actual times recorded against the planned times. If it has not been rehearsed, either schedule the rehearsal or plan for the real cutover to run longer than the estimate, and tell the sponsor which you chose.
The rollback plan has a trigger, an owner, a decision deadline, and a restore that has been tested. Evidence: the written trigger conditions, the name of the person who can call it, the clock time by which the call must be made, and a record of a restore actually performed, not a backup report. If no restore has been performed, treat rollback as unproven and test it before the date.
A change freeze on the legacy system is scheduled and communicated. Evidence: the freeze start time and a notice to everyone who enters data, including field offices, partner agencies, and any vendor that writes to the system. If no freeze is planned, set one, because source records changed after the final extract will not appear in the new system.
Vendor coverage for the cutover window is confirmed in writing. Evidence: names, hours of availability, and escalation numbers, covering nights and weekends if the window reaches them. If coverage has only been promised verbally, get it in email or a contract amendment before the window opens.

Obligations outside the project team are met

Contract acceptance criteria are met, or each deviation is documented. Evidence: the acceptance criteria from the contract, marked met or not met, with unmet items tied to the payment milestone they affect. If criteria are unmet, document the deviation rather than signing acceptance to protect a date, since signed acceptance generally weakens the agency's position in later negotiation.
Required authorizations and reviews are complete. Evidence: the completed privacy review, security authorization, or program sign-off that applies to the data the system holds. Depending on the data, these may involve the CJIS Security Policy, HIPAA, or IRS Publication 1075, and what applies varies by state, program, and contract. If you are not certain which apply, confirm with your privacy or compliance office before the date rather than after it.
Any governing body or oversight approval has been obtained. Evidence: the council, board, or state agency action, with its date. If approval is still pending, check the meeting calendar and the agenda deadline, because those dates, not the project plan, now control the cutover.
Audit logging and retention settings are configured. Evidence: a log sample showing who did what and when, and the configured retention period compared against what the agency requires. If retention is set shorter than required, change the setting before data accumulates, since reconstructing history later is difficult.
Support, continuity, and recovery arrangements take effect at go-live. Evidence: the start date of the maintenance agreement, the support hours, the response commitments, and the backup and recovery arrangements for the new system. If implementation support ends before maintenance begins, close the gap in writing before the cutover.

What to do with the results

Sort every no into two piles: items that block go-live, and items the agency can carry for a defined period with a named owner and a due date. Be strict about the first pile. Data that does not reconcile, an untested rollback, and unprovisioned accounts belong there. A desk reference that has not been rewritten usually does not.

Take the sorted list to the sponsor and the steering group as a recommendation, not as raw status. If the recommendation is no-go, propose a new date and name the work that closes each blocker. A decision that rests on recorded evidence is easier to explain afterward than a date that was met without it.

If the decision is go, publish the carry-forward list and set a stabilization review date to confirm those items closed. Keep the completed checklist with the project record. It documents what the agency knew at the time it decided.

Where HQT fits

HQT offers software development, systems engineering, and technology advisory services. Work of this kind includes implementation planning, test planning and oversight, data conversion review, and independent readiness review before an agency commits to a cutover date.

Frequently asked questions

Who should make the go or no-go decision?

The decision belongs to the agency, normally the project sponsor or the department head who owns the service, acting on the project manager's recommendation. The vendor supplies evidence and its own readiness opinion, but it should not be the deciding voice. Write down who holds the decision before the review meeting so the authority is not in question on the day.

How far ahead of the cutover should we run this checklist?

Run it early enough that a no can still be fixed, then run it again close to the date so the answers are current. The first pass is most useful once conversion rehearsals and user acceptance testing are under way, because that is when evidence exists to check. The second pass belongs shortly before the go-no-go meeting. How much time each pass needs depends on the size of the system and the length of your cutover window.

What separates a blocker from something we can carry forward?

A blocker is anything that could stop the agency from delivering a required service, expose data, or prevent recovery if the cutover fails. Data that does not reconcile, unprovisioned accounts, and an untested rollback belong in that group. Cosmetic defects, reference documents that have not been rewritten, and reports that can wait are usually carry-forward items. Give every carry-forward item an owner and a due date, or it will not close.

Can we go live with open defects?

Open defects do not by themselves stop a go-live. What matters is whether each one has been reviewed, assigned a severity, and accepted in writing by someone with authority to accept the risk. Defects that force staff into workarounds on high volume work deserve closer scrutiny than defects in functions used a few times a year. If nobody is willing to sign the acceptance, treat the defect as unresolved.

The vendor says the system is ready, but our staff are not confident. What then?

Treat staff confidence as evidence rather than sentiment, and ask what specifically is driving the doubt. The answer usually points to a concrete gap such as an untested process, thin training, or an unclear support path. Close the gap and check again, or record the concern and the mitigation in the go-no-go notes before proceeding.

What counts as evidence for an item on this checklist?

Something another person could look at and reach the same conclusion: a signed test script, a run log with times, a reconciliation report, an attendance roster, a written notice with its send date. A verbal assurance from the vendor or from a team member is not evidence, and neither is a status slide. If the evidence for an item cannot be produced within a day of asking, record the item as a no and decide whether it blocks the date.