The CRM Implementation Checklist: 11 Phases We Use With Every Client

A CRM implementation checklist is the difference between a system your team runs the business on and a $100,000 contact database nobody trusts. Most failed implementations didn't fail because of the platform: they failed because steps got skipped, decisions got made ad hoc, and nobody owned the sequence.

This is the 11-phase checklist we run on every Salesforce and HubSpot engagement. Each phase has a deliverable and a sign-off gate. Don't start the next phase until the current one's gate is cleared.

Phase 1: Discovery and requirements

• Interview stakeholders across sales, marketing, ops, finance, and CS.
• Map the current end-to-end process (lead → opportunity → close → onboard → renew).
• Document the pain points and the metrics leadership actually cares about.
• Inventory current systems, integrations, and data sources.

Gate: a requirements document everyone agrees describes reality.

Phase 2: Architecture and design

• Decide the object model (standard vs custom objects).
• Define lifecycle stages, lead-to-contact conversion rules, and pipeline stages.
• Design the field schema, and use this as the forcing function to delete fields you don't need.
• Plan permissions, profiles, and role hierarchy.

Gate: a written architecture decision document, signed off by RevOps and leadership.

The field schema is the part worth slowing down on, because it is the only decision here that is close to irreversible in practice. Adding a field takes thirty seconds and removing one takes a dependency audit, a sandbox test and a fifteen-day recovery window. Every org we are called in to clean up has a few hundred fields and a handful of people who remember what any of them were for.

Phase 3: Data audit

• Count records by object and measure fill rates on every field.
• Run duplicate analysis (exact and fuzzy match).
• Identify stale records and records owned by inactive users.
• Produce a data-quality health report with target metrics.

Gate: you know exactly how clean (or dirty) your data is before you touch it.

That gate sounds like paperwork and it is the one that pays for itself. The numbers you capture here are the only baseline you will ever have: without a duplicate rate and a fill rate from before the cleanse, nobody can tell afterwards whether the cleanse worked or whether the data was always like that. It also settles the argument about scope. "Forty percent of accounts have no owner" ends a conversation that "the data is messy" can run for a fortnight.

Phase 4: Org build

• Configure objects, fields, page layouts, validation rules.
• Set up the sales process, products, and pricebooks if relevant.
• Build permissions and dashboards.
• Build no automation yet: get the model and UX right first.

Gate: a fully configured sandbox that mirrors your target state, minus data and automation.

Phase 5: Data cleansing

• Deduplicate (exact match auto-merge, fuzzy match human-reviewed).
• Normalize key fields (country, state, phone, industry, company name).
• Enrich missing values via Apollo, Clearbit, or ZoomInfo.
• Archive stale records rather than deleting them.

Gate: a clean source dataset with a documented exclusion list. See the full data quality playbook.

Phase 6: Test migration

• Migrate a representative 10–20% sample into the sandbox.
• Validate field mapping, calculated fields, ownership, and relationships.
• Flag and diagnose records that fail to import.

Gate: the sample data lands correctly and the mapping is proven.

Pick the sample badly on purpose. A random ten percent is almost all ordinary records and it will pass, which tells you nothing, and then the full migration meets the interesting ones for the first time in production. Choose deliberately instead: the longest text fields, records with the most related children, anything owned by a deactivated user, names carrying apostrophes and accents, and the oldest records in the system. If those land, the ordinary ones will.

Phase 7: Automation build

• Triage the automation inventory: must-rebuild, should-rebuild, won't-rebuild.
• Build the must-rebuild workflows (lead routing, lifecycle stages, deal automation, notifications, onboarding).
• Decide Flow vs Apex for each per the decision framework.
• Build error handling and monitoring into every workflow.

Gate: must-rebuild automation works against the test data.

Phase 8: Integrations

• Connect billing, marketing, support, and delivery systems.
• Define source-of-truth rules per field to prevent sync wars.
• Build idempotency and loop-prevention into bi-directional syncs.

Gate: integrations move data correctly without creating duplicates.

Bi-directional sync is where this phase actually goes wrong, and it goes wrong quietly. Two systems that both consider themselves authoritative on a field will trade writes forever, each treating the other's update as a change worth propagating, and the symptom is not an error but a record that keeps reverting a few seconds after someone edits it. Decide which side owns each field, in writing, before anything is connected. A field with two owners has none.

Phase 9: User acceptance testing

• Real users from each team find real records, run real reports, complete real workflows.
• Capture every gap and bug.
• Fix issues in priority order. Re-test.

Gate: signed-off UAT from each team. "We tested it ourselves" does not count.

Phase 10: Training and rollout

• Role-based training: end users, power users, admins, each learns what they need.
• Hands-on labs using real workflows, not feature tours.
• Record every session; store docs in your wiki.
• Name a champion on each team for the first 60 days.

Gate: the team knows how to do their job in the new system.

Phase 11: Cutover and hypercare

• Freeze the old system, run the final delta migration, validate record counts.
• Activate automation in production. Run sanity-check reports.
• Daily standups and a triaged issue queue for the first 2 weeks.
• Don't promise "should-rebuild" automation until critical issues are stable.

Gate: stable production, 90%+ active-user adoption, and a closing ticket queue.

Be specific about what adoption means before you measure it, because logins are not usage. A rep who signs in every morning, reads a dashboard and then keeps working out of a spreadsheet counts as active on any login report and has not adopted anything. Measure the thing you actually care about instead: records created and updated per user per week, against what the old system was doing at the same point. That number is harder to reach and it is the one that predicts whether this holds in month six.

The meta-rule: gates, not vibes

The reason this checklist works isn't the steps: it's the gates. Each phase produces something concrete that has to be true before the next phase starts. Implementations derail when teams build automation on un-cleansed data, migrate without UAT, or go live without training. The gates make those shortcuts impossible. The broken implementations we get called into almost always skipped a gate that looked optional at the time and turned out to be the whole project.

Which gate would you fail today?

Read back through the eleven and find the first one your current rollout wouldn't clear.

Most people know before they reach the end of the list, and it's almost never Phase 1. It's usually Phase 3 or Phase 5, because data work is invisible from the outside. A status update looks identical whether the duplicate analysis happened or not, so it's the easiest thing to defer until the migration is already running and the duplicates have become somebody else's problem in production.

Whatever gate you landed on is where this rollout is going to hurt. You found it before your users did, which is the only advantage a checklist ever really gives you.