Go-live is the moment when every shortcut taken during the build becomes visible to real users. A structured readiness review a week or two beforehand is far cheaper than fixing problems while the whole team is trying to work. This article gives you a checklist you can adapt, plus advice on how to run the cutover itself.

Why a Formal Readiness Review Helps

During a project, people tend to assume that someone else has checked the unglamorous items: whether every user can log in, whether the right people can see the right records, whether the imported data is trustworthy. A readiness review turns those assumptions into explicit yes-or-no answers with a name beside each one.

It also creates a clean decision point. If three items are red, you can delay by a few days on purpose instead of launching and apologizing afterwards.

The Checklist

Use the table below as a starting point. Add or remove rows to match your own setup, and assign one owner per row.

Area	What to verify	Typical owner
Users and licenses	Every user exists, is assigned the correct role and can log in	Admin
Permissions	Sample users in each role see only what they should	Admin
Data quality	Sampled imported records match the source; duplicates handled	Data owner
Pipeline and fields	Stages, picklists and required fields match the signed-off design	Process owners
Automation	Each workflow tested with realistic records, including edge cases	Admin
Integrations	Email, calendar and connected tools sync correctly in both directions	Admin or integrator
Reports	Key dashboards load and numbers reconcile with a trusted source	Ops manager
Training	Each role has completed a short session and has a quick reference	Project lead
Support	A named person and channel exist for questions in the first weeks	Project lead
Rollback	A written plan exists for what to do if launch fails	Sponsor and admin

Test With Real Scenarios, Not Just Screens

A common weakness in testing is clicking through each screen once and declaring it works. Instead, run complete scenarios that mirror the day: a new enquiry arrives, gets assigned, is qualified, becomes a deal, and is closed. Then run a service version: a customer reports a problem, a case is logged, escalated and resolved.

Ask frontline users, not just the admin, to run these. They will try things you did not expect, such as editing a record from a phone or merging two contacts, and that is exactly what you want to find out beforehand.

Check Permissions From the User’s Side

Permission mistakes are easy to miss because administrators usually see everything. Log in as, or impersonate where your platform supports it, a representative user in each role. Confirm they can do their job, and just as importantly, confirm they cannot see or edit things that are meant to be restricted. Remember that data protection obligations vary by jurisdiction, so involve your compliance or legal contact where customer data is sensitive.

Plan the Cutover Itself

Decide in advance how the switch will happen.

1. Choose a low-pressure day and time, avoiding month-end or major campaigns.
2. Freeze changes in the old system at an announced moment.
3. Run the final data import and spot-check it before opening access.
4. Announce that the new system is live and the old one is read-only.
5. Keep the project team available for quick questions during the first days.

If the old system must remain available for reference, make it read-only so nobody keeps updating two places.

Prepare a Rollback and a Support Plan

Hope is not a rollback plan. Write down what would count as a launch failure, who decides, and what you would do. For many teams the practical answer is to revert to the previous process for a short period while fixes are made, which only works if the old data was preserved at cutover.

For support, expect a spike of small questions in the first couple of weeks. Setting up one channel and one point person keeps issues visible and prevents the same question being answered ten different ways.

A Hypothetical Example

Picture an admin preparing a launch for a thirty-person sales and service group. During the readiness review, a regional manager logs in as a representative and finds that she can see every account in the company instead of only her region. The permission model had been copied from a test setup. Because the check happened a week before launch, the admin fixes the sharing rules, retests with two more users, and also discovers that one workflow assigns leads to a person who has since left the company. Both issues are resolved quietly before anyone outside the project notices.

Frequently Asked Questions

When should the readiness review happen? Roughly one to two weeks before the planned go-live, which leaves time to fix problems without rushing. Hold a shorter final check the day before.

Who gets to say the system is ready? The executive sponsor makes the final call, informed by the project lead and the process owners. Having one named decision-maker avoids endless debate.

What if some checklist items are still red? Decide for each whether it blocks launch or can be fixed shortly after. Anything involving data loss, wrong permissions or broken core processes should block launch.

How much data should we spot-check? Enough to be confident, and weighted toward your most important and most complex records. Compare a sample by hand against the source rather than trusting import counts alone.

Should we launch to everyone at once? Either approach can work. A pilot group reduces risk and surfaces issues early, while a single cutover avoids running two processes. Choose based on team size and how tightly your processes are linked.

Next Step

Copy the checklist table into a shared document, assign an owner to each row, and schedule a readiness review meeting for one to two weeks before your planned launch date.