# CRM Go-Live Checklist

**SoftwareGlimpse** · Updated 15 Aug 2026  
**Type:** CHECKLIST · **Stage:** IMPLEMENT  
**JTBD:** Launch CRM with sync heartbeat, seat roster, and day-one hygiene.

> Freeze, verify, then open — and staff the first week. Use this in the last days before launch and through hypercare: hold the freeze, prove access and sync on real records, make the open decision on evidence, and give day-one issues a named owner.

## How to use

1. **Enter freeze** — Lock non-essential configuration, publish the approval path, and read the pause criteria.
2. **Audit seats and access** — Reconcile licences with the roster and complete sample logins for each role.
3. **Confirm data and sync** — Attach the cutover sign-off and prove the email sync heartbeat on sample mailboxes.
4. **Run launch-day smoke** — Search, create, advance a stage, set a next step, and open the manager board.
5. **Make the open decision** — Sponsor records open or delay on the evidence; only then send the announcement.
6. **Run hypercare and exit** — Staff the rota, triage daily, watch duplicates and hygiene, then close with an exit review.

## Result key

| Result | Meaning |
| --- | --- |
| Pass | Verified with evidence |
| Partial | Met with limits or a workaround |
| Fail | Does not meet a required check |
| Not tested | No evidence yet — do not invent a Pass |

## Evidence that counts

- A smoke check completed on a real record, with a link or screenshot
- A licence report reconciled against the launch roster
- A dated sponsor decision to open or delay
- A published on-call rota with names and coverage hours

## Evidence that does not count

- “It worked yesterday”
- A change made during freeze without a retest
- An announcement scheduled before the smoke checks ran
- Support that exists only as a group chat with no owner

## Checklist

### 1. Freeze gate

Stabilise the build so launch-day problems are the ones you already know about.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1.1 | Freeze start and end announced | Untested changes landing beside new users cause incidents nobody can explain. | Must-have | Announce the freeze window and exactly what it covers: fields, layouts, stages, automations, and permissions. | | | |
| 1.2 | Emergency change path defined | A total freeze gets ignored quietly; an approval path gets followed. | Must-have | Name who approves a severity-1 change during freeze, where it is logged, and who retests afterwards. | | | |
| 1.3 | Pilot exit and open risks reviewed | Launching over an unresolved pilot defect repeats it at full scale. | Must-have | Read the pilot defect list at the launch briefing and confirm each item is closed or accepted in writing. | | | |
| 1.4 | Pause criteria read in the briefing | Under launch pressure, teams push through the failures they had agreed to stop for. | Must-have | State out loud what would delay the launch, and name who makes that call. | | | |

### 2. Seats, access & data gate

People must be able to get in, and the records waiting for them must be signed off.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 2.1 | Licence report reconciled with the launch roster | Sellers locked out on day one stop trying, and spare seats cost money quietly. | Must-have | Compare assigned licences against the named launch cohort and resolve every difference before launch morning. | | | |
| 2.2 | Sample logins completed per role | Identity and provisioning problems only show themselves at the login screen. | Must-have | Have one seller, one manager, and one admin log in through the real path and confirm each lands on the expected home view. | | | |
| 2.3 | Manager visibility checked on team deals | Managers who cannot see their team’s pipeline revert to spreadsheets in the first week. | Must-have | Log in as a manager and confirm team deals, boards, and forecast views appear as expected. | | | |
| 2.4 | Restricted roles verified as restricted | Over-permissioned launches stay quiet right up until they do not. | Nice-to-have | Confirm a restricted role cannot see or edit records outside its scope. | | | |
| 2.5 | Data cutover signed off or marked not applicable | Launch morning is far too late to discover the load never finished. | Must-have | Attach the migration validation sign-off to the go-live packet, or record explicitly that no migration applies. | | | |

### 3. Launch-day smoke gate

Walk the paths a seller will walk in their first five minutes, on real records.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 3.1 | Login and search for a known record | Users form their opinion of the system in the first few minutes. | Must-have | As a normal user rather than an admin, search a known account and contact and open the related deal. | | | |
| 3.2 | Create a contact and a deal | Creation is the first thing a seller does and the first place required fields bite. | Must-have | Create one contact and one deal with required fields and confirm they save and link correctly. | | | |
| 3.3 | Advance a stage and set a next step | Stage and next step are the spine of every pipeline report you will run this week. | Must-have | Move a deal to the next stage, set owner and next-step date, and confirm both appear in a board filter. | | | |
| 3.4 | Email sync heartbeat green on sample mailboxes | Sync failure is the most common day-one outage and the least visible to the launch team. | Must-have | Send a test message from at least two mailboxes and confirm each lands on the intended contact or deal. | | | |
| 3.5 | Manager board and forecast view open | The first pipeline review of the week depends on these views loading with real filters. | Must-have | Open the pipeline, stuck-deal, and forecast views with the filters managers will use and confirm they load without error. | | | |
| 3.6 | Day-one integrations checked | An integration failing silently creates manual work nobody has assigned. | Nice-to-have | Push one record through each must-have integration and confirm it arrives where it should. | | | |

### 4. Open decision & communications

Going live is a decision taken on evidence, then communicated — in that order.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 4.1 | Sponsor records an open or delay decision | “Live” should mean a decision was made, not that a date arrived. | Must-have | Review the smoke results and gate status with the sponsor and record a dated decision to open or delay. | | | |
| 4.2 | Announcement held until after the decision | Announcing before verification turns a fixable issue into a trust problem. | Must-have | Keep the launch message unsent until the decision is recorded, then send it with first actions and where to get help. | | | |
| 4.3 | Manager brief covers running the week from the CRM | If managers do not switch, nobody below them switches either. | Must-have | Tell managers which board to open, what hygiene to expect in week one, and how to raise issues. | | | |
| 4.4 | Support routes published with the announcement | Users who cannot find help within a minute go back to what they know. | Must-have | Include the intake channel, coverage hours, and severity examples in the launch message itself. | | | |

### 5. Hypercare gate

The first days set the habits. Staff them deliberately and close them explicitly.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 5.1 | On-call rota published with names and hours | Shared responsibility on day one means nobody answers first. | Must-have | Publish admin, IT, and RevOps coverage for the hypercare window, with an escalation path. | | | |
| 5.2 | Single intake channel with severity definitions | Issues scattered across direct messages are never counted, prioritised, or closed. | Must-have | Run one channel or queue and post severity-1 examples: cannot log in, sync down, cannot advance a deal. | | | |
| 5.3 | Daily triage while hypercare is open | Themes stay invisible when issues are handled one at a time. | Must-have | Hold a short daily review of new issues, decisions taken, and anything needing a configuration change. | | | |
| 5.4 | Duplicate and hygiene watch in the first days | Day-one data habits set the standard for the rest of the year. | Must-have | Check new duplicate volume and open deals missing an owner or next step on day one and day three, then send the results to managers. | | | |
| 5.5 | Hypercare exit with owners for what remains | Hypercare that fades away leaves unassigned work and no closure. | Must-have | Hold an exit review covering what closes, what becomes backlog, and who owns admin, seats, and reporting from now on. | | | |

## Worked example

_Hypothetical Launch A / Launch B scenario for teaching the artifact — not a SoftwareGlimpse case study._

**Requirement:** On launch morning, a seller can log in, open a migrated deal, advance a stage, and see a synced email on the record.

| Scenario | Result | Note |
| --- | --- | --- |
| Launch A | PASS | Smoke checks ran an hour before the announcement; two permission errors were fixed before users were told the CRM was live. |
| Launch B | FAIL | The announcement went out on schedule while sync was down for one mailbox group, and support had no named owner until midday. |

**Evidence:** Launch-day smoke log with record links, plus the published hypercare rota.

## FAQ

**What does this checklist deliberately leave out?**

Building the CRM belongs in the CRM Implementation Checklist and moving the records belongs in the CRM Migration Checklist. This one covers the hours around launch: freeze, access, smoke checks, the open decision, and hypercare.

**When should we start it?**

Once pilot exit is in sight — commonly one to two weeks before launch, earlier if the cutover or email sync is complex. Freeze rules, seat reconciliation, and a support rota cannot be invented on the day.

**What can still change during freeze?**

Severity-1 fixes that unblock login, stage moves, or email sync, with written approval and a retest afterwards. Everything else — new fields, cosmetic tweaks, extra automations — waits for the post-hypercare backlog.

**What if smoke checks fail on launch morning?**

Do not announce. Use the pause criteria you read in the briefing, especially if the sync heartbeat or the stage and next-step path failed. A late launch is recoverable; a broken first day costs you the adoption you spent months building.

**How long should hypercare last?**

Commonly a few days to two weeks, depending on team size and cutover risk. Define the window up front, staff the duplicate and sync watches, and close it with an exit review rather than letting it fade.

**Does a phased rollout repeat this checklist?**

Yes — run the same gates for each wave. The freeze and smoke checks get faster each time, but seats, access, sync, and support coverage are specific to the group you are opening.

## Related journey

1. [CRM Implementation Checklist](https://softwareglimpse.com/resources/crm-implementation-checklist/)
2. [CRM Migration Checklist](https://softwareglimpse.com/resources/crm-migration-checklist/)
3. **CRM Go-Live Checklist** (this resource)
4. [CRM Training Plan](https://softwareglimpse.com/resources/crm-training-plan/)

## Related tools

- [CRM Implementation Planner](https://softwareglimpse.com/tools/crm-implementation-planner/)
- [CRM Migration Planner](https://softwareglimpse.com/tools/crm-migration-planner/)
- [CRM Finder](https://softwareglimpse.com/tools/crm-finder/)

---

Source: https://softwareglimpse.com/resources/crm-go-live-checklist/