This checklist covers the last stretch of a CRM implementation, from the final migration rehearsal to the first weeks after launch. It's vendor-neutral, so it applies whichever CRM you've chosen. Each check names who owns it, the evidence to look at and whether a failure stops the launch.
Use it in the go/no-go meeting. A check passes when the evidence is in front of the people deciding, not when someone reports that it's done.
How to Use the Checklist
Each check has an owner, the evidence that shows it passed, and what happens if it fails:
Owners are roles, and one person may hold several. The sponsor makes the final call. The CRM lead configures the system, the data lead runs the migration, the integration owner looks after connections to other systems and the privacy owner is responsible for how customer information is handled.
Microsoft's go-live checklist for Dynamics 365 is a useful reference on testing, cutover and sign-off. The checks below apply similar ideas to any CRM, with a decision rule for each.
Scope, Stages and Ownership
| Check | Owner | Evidence | If it fails |
|---|---|---|---|
| 1. Outcomes and scope agreed | Sponsor | A one-page scope: the outcomes this release must support, the teams and processes included, and what's deferred | Blocks launch |
| 2. Lifecycle stages defined | Sales manager | An entry rule, exit rule and required fields for each stage, matching what's configured | Blocks launch |
| 3. Ownership rules set | Sales manager | Owner rules for leads, deals and accounts, including leave and departures, and no open record without an owner | Blocks launch |
If two people could put the same deal in different stages, the stage definitions aren't finished. Our CRM implementation page shows an illustrative lifecycle with entry rules and owners.
Data Migration and Reconciliation
| Check | Owner | Evidence | If it fails |
|---|---|---|---|
| 4. Source IDs kept | Data lead | Every source listed, and each migrated record holding its source system and original ID in its own field | Blocks launch |
| 5. Counts and exclusions explained | Data lead | Record counts for each object in the source and the CRM, with every excluded record covered by a written rule | Blocks launch |
| 6. Open records reconciled | Data lead and sales manager | Open deals match the source on count, total value, stage and owner, plus a field-by-field check of a sample | Blocks launch for open deals; owner may accept small gaps in closed history |
| 7. Duplicates resolved | Data lead | A duplicate report under the agreed match rules, with uncertain matches listed for a person to review | Owner may accept a short, listed review backlog |
"Some old records didn't come across" isn't evidence; a count for each written rule is. Original IDs let anyone trace a figure in the new CRM back to its source.
Permissions, Consent and Retention
| Check | Owner | Evidence | If it fails |
|---|---|---|---|
| 8. Permissions tested by role | CRM lead | A test login for each role, showing what it can see, edit, delete and export, including what it shouldn't | Blocks launch |
| 9. Suppression and consent carried across | Privacy owner | Opted-out contacts excluded from the marketing lists and automations their opt-out covers, by channel and consent scope; consent source and date kept with each record; and a test marketing message to a suppressed test contact blocked | Blocks launch |
| 10. Retention decided | Privacy owner | A written decision on what is migrated, archived or left behind, with where the archive is kept and who can open it | Owner may accept, if the archive is secured |
Carry across when and how consent was given, not just a yes or no flag, and what each opt-out covers. An unsubscribe from marketing email may not apply to service messages such as appointment confirmations, so suppression follows the channel and the consent scope. For commercial email and SMS, the ACMA's guidance on avoiding spam covers consent, identifying the sender and unsubscribing.
Integrations and Test Data
| Check | Owner | Evidence | If it fails |
|---|---|---|---|
| 11. Failure paths defined | Integration owner | For each integration: what happens when the other system is down or rejects a record, who is alerted, and how a failed record is retried | Blocks launch for enquiry and sale integrations; owner may accept for low-risk syncs with a manual workaround |
| 12. Duplicates prevented | Integration owner | A retry carrying the same submission ID leaves one record and one task, while a genuinely new enquiry from an existing contact still gets its own task | Blocks launch |
| 13. Test contacts realistic | CRM lead | Clearly marked test records covering the awkward cases below, removed or excluded before launch | Blocks launch |
Realistic test contacts find the problems clean ones hide. Include a contact with no phone number, two people at the same company, an existing customer enquiring again, an opted-out contact and a very long business name.
Integrations that need alerts, safe retries and a manual fallback are part of business process automation. Where a system has no usable API or export, confirm an authorised way to get at the data before planning a custom integration or a scheduled import. If there isn't one, keep a manual process for that step.
Sales Tasks, Testing and Training
| Check | Owner | Evidence | If it fails |
|---|---|---|---|
| 14. Tasks and next actions ready | Sales manager | Every open deal has a dated next action, new enquiries create a task for their owner, and each rep's day-one task view is populated | Blocks launch |
| 15. Acceptance testing by real roles | Sponsor, with each team lead | Each role's test scripts completed by people in that role, on migrated data, with their own permissions, and defects logged | Blocks launch for defects in core scripts; owner may accept minor ones |
| 16. Training completed | Team leads | Training on each role's own scenarios, a short guide per role and a named first point of help | Owner may accept a few absences, with catch-up sessions booked |
Testing as an administrator hides permission problems, and testing on made-up data hides migration problems.
Cutover, Rollback and the First Weeks
| Check | Owner | Evidence | If it fails |
|---|---|---|---|
| 17. Cutover and rollback rehearsed | CRM lead and sponsor | A timed runbook with owners covering the edit freeze in the old system, the final migration and its checks, plus a written rollback trigger and steps | Blocks launch |
| 18. Adoption and reconciliation scheduled | Sponsor and data lead | Owners and dates for daily checks in week one and a review at two to four weeks: activity by role, records kept outside the CRM, integration errors, and counts against source systems still running | Blocks launch |
Agree the rollback trigger before launch day, while nobody is under pressure. For example: if new enquiries aren't reaching their owners by midday, return to the old process and re-enter anything that arrived in the meantime.
Which Failures Block Launch
A failure should block launch when it could lose or misroute a customer, show information to the wrong person, contact someone who has opted out, stop the team doing core work on day one, or leave no way to spot and recover from a problem. Anything else can be accepted, by the right person and on the record:
A Worked Acceptance Example (Illustrative)
Here's how part of a go/no-go record might read. The business and figures are made up; this isn't a client project.
Context: A fictional service business moving from an old CRM and two spreadsheets.
Check 5, counts and exclusions: 4,200 source contacts, of which 3,962 migrated and 238 were excluded (191 merged duplicates, 32 test records, 15 with no name, email or phone), each under a written rule. Pass.
Check 6, open records: 180 open deals in the source and the CRM, the same total value, and a 25-deal sample matching on stage, owner and value. Pass.
Check 12, duplicates prevented: a test enquiry retried after a forced timeout created two contacts and two tasks. Hold. The integration now reuses the form's submission ID on every retry and applies the agreed contact-matching rules before creating a record. On retest: one contact and one task, while a separate new enquiry from the same test contact still got its own task. Pass.
Check 7, duplicates resolved: 14 uncertain matches (same name, different email addresses) are left for a person to review, not merged. Accepted by the sales manager and assigned to the sales coordinator, for review by the end of week one.
Check 16, training: two of nine users missed their session. Accepted by the sponsor, with catch-up sessions booked before they start using the CRM.
Decision: Go, with two accepted gaps, each owned and dated.
Every decision points to evidence, the hold was fixed and retested before launch, and each accepted gap has an owner and a date.