Go-live is the moment every implementation works toward, and it is also the moment many of them go wrong. Launch too early and the customer meets broken integrations, untrained users and missing data on day one. Launch too late and momentum fades, the sponsor loses patience and the value the customer bought keeps slipping further away.
Go-live readiness is the discipline of deciding, with evidence, that a customer is ready to launch. It replaces "we think we're ready" with a clear set of criteria both sides have agreed to and checked. It also looks past launch day, because going live is not the same as getting value.
This guide covers how to define go-live criteria for a B2B SaaS implementation, how to run a readiness review, what belongs on a readiness checklist and how to drive activation after launch. It draws on Quivly's Forward Deployed Engineers, Projects and Onboarding at Scale pages.
Why Go-Live Readiness Needs a Clear Definition
Without a definition, go-live readiness becomes a feeling. The implementation lead feels the configuration is close, the customer feels pressure from a date they announced internally and someone decides to launch. The gaps only surface once real users arrive.
A clear definition does three things. It gives both teams the same target, so nobody is surprised by what "ready" means. It makes the remaining work visible, so blockers get attention before the launch date rather than after. And it creates a record of what was checked, which helps when something unexpected happens in production.
Quivly's example rollout plan shows readiness built into the structure of an implementation. The plan moves through four phases: Discovery, for scope and questionnaire; Integrate, for connectors and mappings; Validate, for UAT and data checks; and Cutover, for production go-live. Readiness is tracked separately for engineering, CS alignment and security review, and cutover gates must be cleared before launch.
Define Go-Live Criteria Early
Go-live criteria should be agreed long before the launch date, ideally during scoping or at kickoff. Writing them late invites a debate about what counts, at exactly the moment everyone wants to move fast. Good go-live criteria are:
- Specific. "SSO enabled for all users in the first team" rather than "access set up".
- Checkable. Each one can be confirmed as done or not done, with evidence.
- Owned. A named person on each side is responsible for confirming it.
- Limited. Only what is truly required to launch, with nice-to-haves moved to a later phase.
Keep go-live criteria separate from value criteria. Go-live means the system works in production for the people who need it. Value means the customer is getting the outcome they bought the product for. Both matter, but mixing them makes go-live a moving target. Track value through success metrics and a review cadence after launch, which Quivly's sample implementation tasks include as a distinct step.
The Go-Live Readiness Checklist
Every product is different, but most B2B SaaS readiness checklists cover the same core areas. Use these as a starting point and adapt them to your implementation:
- Access and identity. SSO and team access provisioning are configured and tested, and the right people have the right permissions.
- Integrations. Every in-scope integration is connected, field mappings are confirmed and data is flowing as expected.
- Data. Initial data migration is complete and validated, and a migration dry-run has been run where cutover involves moving live data.
- Testing. User acceptance testing is complete and signed off by the customer.
- Security and compliance. Any required security review is finished, not still queued.
- Training. End users and admins have been trained, and a handoff checklist is in place.
- Support and escalation. The customer knows how to get help after launch and who to contact for what.
- Success measures. Success metrics and a review cadence for the weeks after launch are agreed.
Quivly's example tasks map closely to this list: completing technical discovery, setting up SSO and team access, configuring pipeline integration, running initial data migration and validation, conducting end-user training with a handoff checklist and establishing success metrics and a review cadence. Its example cutover gates are SSO and provisioning, a migration dry-run and a training session.
Run a Readiness Review Before Cutover
A readiness review is a short, structured meeting held a few days before the planned launch. Its job is to make a clear go or no-go decision based on the checklist, not on optimism. A simple format:
- Walk the checklist. Confirm each item as done, at risk or not done, with evidence for anything marked done.
- Review open risks. Look at blockers and anything that has slipped, and decide whether it affects launch.
- Check customer readiness. Confirm the customer's team, communications and internal support are ready, not just the configuration.
- Agree the decision. Go, go with conditions or delay to a new date.
- Record it. Write down the decision, the reasons and any conditions on the project itself.
A delayed launch is not a failure if it is decided early and for good reasons. A rushed launch that damages the customer's first impression is far more expensive. Quivly's rollout plan shows slipped dates rolling forward to dependent milestones, so a delayed cutover automatically updates everything that depends on it.
Make Readiness Visible to Both Teams
Readiness breaks down when the implementation team and the customer are looking at different information. The vendor thinks it is waiting on the customer, the customer thinks it is waiting on the vendor and nobody notices until the launch date arrives.
Shared visibility fixes this. Quivly's FDE page describes milestone templates with dependencies and automatic status rollups, customer readiness gates tied to technical checkpoints and a shared timeline visible to CS and engineering. On the Projects page, forms collect the files, screenshots and answers the team is waiting on, such as SSO metadata and an admin console screenshot, and requests go out through Slack, email and a customer portal.
Agents can help keep the picture current. Quivly's Projects page describes agents that turn a conversation into a proposed task, risk or blocker with the evidence attached, while a person still decides whether to apply it. For more on running implementation work collaboratively, see our guide to vendor and customer collaboration during implementation.
Go-Live Is Not the Finish Line: Drive Activation After Launch
The most common mistake after launch is treating go-live as the end of the project. Users are in the system, but that does not mean they are getting value. The weeks after launch decide whether the implementation turns into adoption.
Quivly's onboarding page describes a default journey with milestones that continue past launch: workspace provisioned, core integration live, first value event, team trained and health review. It maps each new account against these milestones in real time and flags when an account falls behind, such as a missed setup step, a stalled integration or a team that has not logged in.
Useful post-launch activation steps include:
- Watch for the first value event. Define the action that shows a customer is getting real value, and track how long it takes to reach it.
- Activate every key stakeholder. Quivly tracks engagement at the contact level, so it can spot when the IT admin, power user or exec sponsor has not been activated.
- Intervene early. Quivly can send a personalised check-in, create a CSM task with full context or route to a solutions engineer when an account stalls.
- Hold the first review. Use the agreed success metrics to review progress with the customer a few weeks after launch.
Our guide to onboarding milestones covers how to define the milestones after go-live, and our article on measuring time to value explains how to track the path to first value.
Want every launch decision backed by a clear readiness picture both teams can see? See how Quivly Projects brings milestones, cutover gates and customer inputs into one shared workspace from kickoff to go-live and beyond.
FAQ
Go-live criteria are the specific, checkable conditions that must be true before a customer launches in production, such as SSO configured, integrations connected, data migrated and validated, UAT signed off and users trained.
The implementation lead or forward deployed engineer usually runs the readiness review, but the decision should be shared with a named customer stakeholder who confirms their team is ready.
Decide early whether to delay or launch with conditions, record the reasons and update dependent milestones. A planned delay is far less costly than a rushed launch that damages the customer's first impression.
Go-live means the system works in production. Activation means the customer's users are reaching meaningful value events, which is what drives adoption and, eventually, renewal.
