A well-run implementation front-loads scope decisions, protects the data on the way in, and ships a system reps actually open on launch day. Scope creep, bad data, and a missing executive sponsor are the three failures that stretch a six-week project into a six-month one.
CRM implementation is the project of standing up a new customer relationship management system from scratch. It covers six phases: discovery, design, configuration, data migration, training, and launch. Teams run it in-house or with an implementation partner, and the timeline runs from two weeks for a small team to twelve months for an enterprise rollout. The goal is a working system reps use on day one, not a blank tenant waiting for data.
The implementation project in six parts: what it is, the six phases every rollout runs, who does the work, how long it takes, where it fails, and how to tell the system is ready to launch.
Buying the license is one afternoon. Implementation is the project that turns a blank tenant into a running system: data loaded, pipelines configured, automations wired, reports built, team trained, and the first week of real activity flowing without the old spreadsheet alongside it. Teams that skip the project end up with an empty CRM and a sales floor still working out of inboxes.
Discovery captures how the team sells today. Design turns that into a target state. Configuration builds the tenant to match. Migration moves contacts, accounts, and open pipeline from the old system. Training walks reps and managers through the surfaces they will use daily. Launch retires the old tool and starts the clock on real usage. Skip a phase and the next one pays for it.
Small teams on configuration-first platforms run implementation in-house with a RevOps lead and an exec sponsor. Mid-market and enterprise teams usually hire an implementation partner, because the project drops into the critical path for a quarter and the partner has shipped the pattern a hundred times. Hybrid splits the work: partner for data model and migrations, internal team for configuration and training.
A five-seat SMB on a configuration-first platform ships in two to six weeks. A fifty-seat mid-market team with custom objects, integrations, and a real migration runs two to four months. A multi-region enterprise with a code-first platform, legacy data, approvals, and compliance review runs six to twelve months. These are working projects, not elapsed clock time, so staffing drives the bracket as much as scope.
Three failures account for most late or dead implementations. Scope creep happens when the discovery phase keeps running after configuration starts. Bad data happens when the old system is loaded without cleanup, so the new CRM inherits every duplicate and every stale field. A missing executive sponsor means the project loses its tiebreaker, and every scope question becomes a meeting instead of a decision.
A CRM is ready to launch when the five launch-readiness lines all pass: data loaded and spot-checked, pipelines and stages matching how the team actually sells, automations tested on real records, reports built for the three meetings that happen weekly, and training delivered to every seat with a recorded replay for new hires. If any line fails, the launch slips, not the test.
Every rollout, from a five-seat SMB to a thousand-seat enterprise, runs the same six phases in the same order. The difference is depth, duration, and how many stakeholders sit in each phase. Below is the view that implementation partners use internally, with the real work behind each label.
Interviews with sales, marketing, service, and ops. A map of the current pipeline stages, the hand-off points, the fields the team actually uses, and the reports leadership runs every week. Access to the old system so the data shape is known before design starts. The output is a short document that lets every stakeholder nod at the same picture of today, which is the only reliable base for the target state.
The data model (objects, fields, relationships), the pipelines and stages, the role-based permissions, the automations and triggers, the reports and dashboards, and the integrations with email, calendar, phone, and billing. Design is where tradeoffs happen while they are still cheap: one pipeline or three, custom objects or custom fields, forecast weighted by stage or by rep override.
A tenant is created, the data model is built, pipelines and stages are added, permissions are assigned by role, automations are wired, reports are built, and integrations are connected. On configuration-first platforms this is admin-UI work. On code-first platforms it is a mix of UI, declarative tools, and actual code. The output is a working tenant that mirrors the design document, with no data yet.
Contacts, companies, open deals, closed deals, activities, and attachments are exported from the old system, cleaned, deduplicated, mapped to the new data model, and imported. Open deals keep their stage and close date so the pipeline survives the cutover. Closed deals come in so win-rate and cycle-time reports have history on day one. The migration script is run twice: once on a sandbox, once on production.
Reps learn the deal board, activity logging, and mobile. Managers learn the pipeline review, the forecast, and the reports they will run every Monday. Admins learn how to add fields, build reports, and adjust automations without filing a ticket. Training is role-based, recorded, and short, because a two-hour overview session never survives contact with the first real quarter.
The old CRM is read-only or archived. The new CRM is the system of record. Automations go live. Hypercare starts: a dedicated channel for the first two weeks, daily standups for the first week, and quick turnarounds on bug reports. The project does not close at launch, it closes when the first full pipeline review and forecast cycle ran inside the new system without surprises.
The staffing question runs alongside the platform question. A configuration-first platform with a strong admin UI is implementable in-house by a RevOps lead. A code-first platform with heavy customization usually needs a partner. The frame below is the one buyers use when deciding where to spend the implementation budget: inside, outside, or split.
Works best for small and mid-market teams on configuration-first platforms. The RevOps lead owns the project day-to-day: discovery, design, configuration, and training. The exec sponsor owns scope decisions and timeline tradeoffs. Cost is internal staff time, usually two to three days a week for the project duration. Risk is bandwidth: the lead still has a day job.
The partner brings a methodology, a project manager, a solution architect, and sometimes a data engineer. They have shipped the platform fifty times, so the design phase is faster and the migration script is already written for the usual edge cases. Cost is a fixed statement of work. Typical for mid-market and enterprise rollouts on code-first platforms, or any rollout where the internal team cannot carve out the hours.
The partner handles data model design and migration, the two phases where mistakes are most expensive. The internal team handles configuration, training, and launch, the three phases where ownership drives adoption. Common on configuration-first platforms once the project outgrows a single RevOps lead but does not warrant full partner engagement. Keeps the muscle memory inside the company.
Many vendors offer onboarding packages. Useful for configuration-first platforms where the vendor team knows every edge case of their own product. Watch for the ceiling: vendor PS teams rarely do deep business-process redesign, so if the discovery phase is where the real work lives, a partner usually brings more value. Treat vendor onboarding as a launchpad, not a full implementation.
Good fit when the project is scoped but needs hands. Common for a specific slice: build the migration script, build the reports, build the integrations. Lower cost than a partner engagement, higher risk if the project spans multiple workstreams, because a single contractor becomes the bottleneck and the sole point of failure for timeline.
Pick in-house if the platform is configuration-first, the team is under fifty seats, and a RevOps lead has real capacity. Pick partner-led if the platform is code-first, the team is over fifty seats, or compliance requires process documentation at every step. Pick hybrid when the migration is complex but the day-to-day team wants ownership of the resulting system. Vendor PS and freelancer fit specific slots inside those three.
Published timelines come from the glossy case studies. Real timelines come from the project tracker. The brackets below are working project time, which means an SMB rollout labeled "two to six weeks" is six weeks of active project work, not six weeks of elapsed calendar time with vacation and quarter-close baked in.
Five to twenty-five seats, one or two pipelines, light customization, a clean migration from a spreadsheet or a lightweight CRM. Run in-house or with vendor onboarding. The six-week version includes a migration from an older CRM with a real customer history. The two-week version is a greenfield team moving off spreadsheets.
Twenty-five to one hundred seats, multiple pipelines (new business, renewals, expansion), custom objects, integrations with email, calendar, phone, document generation, and billing, migration from an incumbent CRM with several years of history. Usually partner-led or hybrid. The two-month end requires a focused team. The four-month end absorbs an integration or two that slip.
One hundred to a few thousand seats, multiple business units, multiple regions, approval workflows, compliance review, change management, and often a code-first platform. Partner-led, with vendor engagement and internal program management. The six-month end requires a dedicated program team. The twelve-month end is the realistic case when any of the three usual pitfalls shows up.
The same scope on a configuration-first platform ships weeks faster than on a code-first platform, because admin-UI changes do not require a build, a review, or a deployment. The leverage compounds in later phases: automations are faster to wire, reports are faster to iterate, and the training deck does not have to explain a developer handoff for every tweak the team wants after launch.
A sharp data model up front, a single source of truth for migration data, a frozen stage list, and a published go-live date that leadership defends. Every unresolved question in those four areas pulls hours out of every later phase. Teams that lock the data model in week one usually launch inside the lower end of their size bracket.
Discovery that keeps running after configuration starts. A migration that uncovers data problems nobody owned. A stakeholder who did not sit in discovery and now wants the pipeline redesigned. A compliance review scheduled late. A vendor integration that quietly moved to the vendor roadmap. Any one of these adds weeks. Two of them stacked double the project.
Implementation does not fail in configuration. It fails before configuration starts (scope and sponsorship) or after it ends (data and adoption). The six cards below cover the recurring pitfalls, the launch-readiness checklist, and the platform choice that drives how heavy the whole project is.
Discovery that never ends, a design document that gets reopened every week, and a configuration phase that restarts the data model three times. Fix is a frozen scope at the end of design, a formal change process after that, and an executive sponsor who says no on behalf of the project. Scope creep is the single most common reason an eight-week project becomes a six-month one.
The old system had duplicates, blank required fields, and stale ownership. If the migration script lifts the data as-is, the new CRM inherits every problem on day one. Fix is a cleanup pass before migration: deduplication, required-field backfill, ownership reassignment, and a test import on a sandbox. Launch slips are better than launching into dirty data that reps stop trusting in week two.
Without a sponsor, every scope question becomes a committee decision, every scope decision becomes a political one, and the project loses its tiebreaker. The sponsor does not run the project day-to-day. They own the "we are launching on this date, these are the trade-offs, these are the decisions" conversations with leadership. Without that role filled, implementations drift.
Data loaded and spot-checked against the old system. Pipelines and stages match the actual sales motion. Automations tested end-to-end on real records in a sandbox. Reports built for the three recurring meetings (pipeline review, forecast, exec review). Training delivered to every seat with a recorded replay. If any line fails, the launch slips, not the test. Shipping on an incomplete checklist is how adoption dies in month two.
Configuration-first platforms do most of the work in admin UI: fields, objects, layouts, automations, and reports. Implementations are weeks, not months, and internal teams can own the system after launch. Code-first platforms require developers for most changes, so implementations run longer and ongoing work has a build-release cycle. Neither is wrong. The question is whether the business process is simple enough for configuration-first to absorb, or complex enough that code-first leverage pays back.
Hitting the go-live date is not the finish line. The finish line is one full pipeline review, one full forecast cycle, and one full close-of-quarter month inside the new CRM, with no fallback to the old system and no spreadsheets patching gaps. Keep the hypercare channel open until that point. Projects declared done at launch instead of after the first cycle are the ones that leak adoption six weeks later.
Strkr is a configuration-first platform: custom objects, custom fields, pipelines, automations, and reports all live in admin UI. CRM, marketing, projects, and documents share one data model, so the implementation project is one rollout, not four.
Six phases in order: discovery (how the team sells today), design (the target state), configuration (build the tenant), migration (move the data), training (role-based, recorded), and launch (retire the old tool, start hypercare). The project closes after the first full pipeline review and forecast cycle run inside the new system without surprises.
Two to six weeks for a small team on a configuration-first platform. Two to four months for a mid-market rollout with custom objects, integrations, and a real data migration. Six to twelve months for an enterprise project with multiple business units, approvals, and compliance review. These are working project timelines, not elapsed calendar time.
Hire a partner when the platform is code-first, the team is over fifty seats, or compliance requires documented process at every step. Run in-house when the platform is configuration-first and a RevOps lead has real capacity. A hybrid model (partner for data model and migration, internal team for configuration and training) is common for mid-market rollouts that want ownership.
Implementation is standing up a new CRM from scratch, including greenfield rollouts where there was no prior system. Migration is the subset of implementation that moves data and process from an existing CRM to a new one. Every migration is an implementation, but not every implementation is a migration. A team moving off spreadsheets runs an implementation without a migration phase.
Scope creep. Discovery that never ends, a design document that gets reopened every week, and a configuration phase that restarts the data model multiple times. The fix is a frozen scope at the end of design, a formal change process after that, and an executive sponsor empowered to say no on behalf of the project.
Executive sponsor named. Data model and pipeline stages signed off. Migration script tested on a sandbox. Automations tested end-to-end on real records. Reports built for pipeline review, forecast, and executive review. Role-based training delivered and recorded. Hypercare channel open for the first two weeks. Old CRM in read-only mode. First pipeline review and forecast cycle completed inside the new system.
The cost splits across three lines: internal staff time (always the biggest line, even for partner-led projects), partner or vendor professional services fees if used, and incidental tools for migration and training. SMB rollouts can run almost entirely on internal time. Mid-market and enterprise projects usually need external help scoped to the data model, migration, and change management work.
A consulting firm that specializes in rolling out one or more CRM platforms. The partner brings a project manager, a solution architect, and sometimes a data engineer or developer. They have shipped the same platform many times, which shortens discovery and makes the migration script a reusable asset instead of a bespoke write. Partners usually bill a fixed statement of work.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
