Skip to content
All insights
Salesforce By Watson Lake Technology · May 14, 2026 · 7 min read

Salesforce Implementation Timeline: What to Expect in 2026

Phase-by-phase breakdown of how long a Salesforce implementation actually takes — Sales Cloud, Service Cloud, and Experience Cloud — and what makes timelines slip.

The most common question we hear after “how much does this cost?” is “how long will it take?” And the honest answer — like the cost answer — is that it depends. But “it depends” without specifics is not useful.

Here is the phase-by-phase breakdown for real implementations, with the variables that compress or extend each phase.

The short version

Project typeTypical timeline
Sales Cloud basics (SMB, clean data, minimal integrations)4–8 weeks
Sales Cloud + Service Cloud (mid-market)8–16 weeks
Experience Cloud portal (partner or customer community)6–12 weeks
Full enterprise implementation (multiple clouds, complex integrations, data migration)16–32 weeks
Admin rescue / org cleanup2–6 weeks

These assume locked requirements at kickoff and a client-side champion with authority to make decisions. Both are rarer than they should be.

The standard phases

Every Salesforce implementation, regardless of size, goes through the same phases. What varies is how long each phase takes.

Phase 1: Discovery and scoping (1–3 weeks)

This is where requirements get documented, the current state gets mapped, and the implementation approach gets agreed on in writing. Short implementations do this in a week. Complex ones — multiple clouds, integrations, data migration — can take two to three weeks to scope correctly.

What extends this phase: vague requirements (“we want Salesforce to work better”), too many stakeholders with conflicting opinions, no existing documentation of current processes, and clients who want to start building before scope is locked.

What compresses it: a client-side project owner who can make decisions, documented current-state processes, and a clear definition of “done” for the go-live milestone.

Phase 2: Environment setup and configuration (2–6 weeks)

Sandboxes created, org settings configured, objects and fields built, page layouts set, record types established, validation rules written, permission sets created. This is the largest phase in most implementations and runs in parallel with integration development.

Standard Sales Cloud configuration with no custom Apex can be done in two to three weeks. Add Service Cloud and the configuration surface area roughly doubles. Add custom Apex, Lightning Web Components, or complex approval logic and you are looking at four to six weeks minimum.

Phase 3: Integrations (2–8 weeks, often parallel to Phase 2)

Every third-party system that talks to Salesforce is its own workstream. Simple integrations — a webhook to push form leads into Salesforce, a Zapier connection to a marketing platform — can be done in a few days. A bidirectional sync between Salesforce and an ERP like NetSuite or SAP with conflict resolution, field mapping, error handling, and monitoring is four to eight weeks of work.

Integrations are the most common source of timeline overrun in mid-market implementations. They almost always reveal data quality problems, schema mismatches, and undocumented edge cases that were not in the original scope.

Phase 4: Data migration (2–6 weeks, often parallel)

Clean data in a single CSV that maps cleanly to Salesforce objects can be migrated in a few days. Legacy data — multiple source systems, duplicate records, inconsistent field formats, broken relationships — can consume as much of the project as configuration and integrations combined.

The variables that matter most: how many records, how many source systems, how clean the data is, and whether transformation logic is needed before loading. A team that waits until Phase 4 to start thinking about data migration almost always runs late.

The right approach: start your data audit in Phase 1. Know your record counts, identify your deduplication strategy, and flag the fields that will need transformation before a single sandbox is created.

Phase 5: Testing and UAT (1–3 weeks)

Internal QA first — the partner tests against requirements. Then user acceptance testing, where the client’s team validates that the system matches what they asked for and how they actually work.

UAT is consistently underestimated. Business users find edge cases that were not in the requirements. They also find requirements that were documented but not what they actually wanted. Two weeks of UAT with a responsive decision-maker who can approve or reject findings is standard. Three weeks if the scope is large.

What extends this phase: UAT participants who are not available or not engaged, findings that require scope changes (new requirements smuggled in as “bugs”), and no clear definition of what constitutes a launch blocker vs. a post-launch improvement.

Phase 6: Training and go-live (1–2 weeks)

Admin training for whoever will maintain the org. End-user training for the teams who will actually use it. Go-live plan with a rollback option. Cutover executed.

The go-live itself — flipping the switch — is usually a few hours if the migration is clean and the integrations are tested. The two weeks around it are planning, dry runs, and making sure every end user knows what to do on day one.

Phase 7: Hypercare (2–4 weeks post-launch)

The period immediately after go-live when the partner is on standby for issues, adoption questions, and the inevitable “this is slightly different from how we work in practice” adjustments. A clean implementation with good training can get through hypercare in two weeks. A complex one with many end users and tight integrations might need four.

A worked example: 12-week Sales Cloud + Service Cloud

For a mid-market B2B company with 30 Sales Cloud users, 10 Service Cloud users, clean data in one legacy CRM, and two integrations (HubSpot sync, billing webhook):

WeekWork
1–2Discovery, requirements, scope sign-off
3–5Sales Cloud config, object model, page layouts, validation rules
4–7Service Cloud config, queues, routing, case management (parallel)
4–8HubSpot integration, billing webhook integration (parallel)
5–7Data migration: audit, mapping, transformation scripts, test loads
8–9Internal QA, integration testing, data validation
10–11UAT with client team, bug fixes, requirement adjustments
11–12Training, go-live, cutover
13–14Hypercare

Total: 12 weeks to go-live, 14 weeks to end of hypercare. This assumes locked requirements, available data, and a client champion who can make decisions within 24 hours.

What kills timelines

Scope creep. The single largest timeline killer. “While you’re in there, can you also…” adds days or weeks without anyone making an explicit decision. Fixed-fee engagements with formal change orders protect against this. T&M contracts with no ceiling do not.

Late data readiness. Discovering three weeks in that the data export from the legacy system is messier than expected, or that two source systems need to be merged. Start the data audit at the beginning.

Unavailable stakeholders. UAT requires business users to show up, test, and make decisions. If the person who needs to approve UAT findings is unavailable for two weeks, the project is unavailable for two weeks.

Changing requirements. Every requirement that changes after Phase 2 has started costs two to four times what it would have cost to get right in Phase 1.

Integration surprises. The external API behaves differently than documented. The ERP has a rate limit no one mentioned. The authentication scheme changed since the integration was scoped. These are normal — and they add days.

What compresses timelines

Data ready at kickoff. The fastest implementations we have delivered were ones where the client handed us a clean, validated export from their legacy system on day one of the engagement.

A locked scope document. Signed before work starts. New requirements are change orders, not favors.

A client champion with authority. One person who can approve a direction within a business day. Not a committee that meets weekly.

Phased rollout. Going live with Sales Cloud first, then adding Service Cloud, then integrations — rather than launching everything at once — dramatically reduces go-live risk and often cuts the time-to-first-value in half.

Realistic UAT participation. Block time on calendars before the project starts. Treat UAT like the deadline it is.


Frequently asked questions

How long does a Salesforce implementation take from signing to go-live? For a focused Sales Cloud implementation, four to eight weeks is realistic. Sales Cloud plus Service Cloud for a mid-market team runs eight to sixteen weeks. Full enterprise implementations with multiple clouds, integrations, and data migration from a legacy system typically run sixteen to thirty-two weeks. The biggest variable is almost always data quality and integration complexity, not configuration.

What causes Salesforce implementations to go over timeline? The most common causes are scope creep (new requirements added after Phase 2 begins), late discovery of data quality problems, unavailable stakeholders during UAT, and integration surprises. Most timeline overruns are preventable with a locked scope document, a data audit completed in Phase 1, and UAT participants who are genuinely available.

Can I do a Salesforce implementation in phases? Yes — and we recommend it for any implementation with significant scope. Going live with Sales Cloud first, then adding Service Cloud, then integrations, reduces go-live risk and cuts time-to-first-value substantially. The phased approach also surfaces process gaps and user feedback before the full scope is built, which often saves rework.

How long is the Salesforce go-live process itself? The actual cutover — migrating live data, switching integrations to production, shutting down the legacy system — typically takes four to twelve hours if the preparation is done correctly. The two weeks around it (dry runs, training, communication to end users, rollback plan) are what take time, not the cutover itself.

What should we have ready before an implementation starts? The three things that make the biggest difference: a documented list of current processes (even rough notes are better than nothing), a complete export or audit of the data that needs to migrate, and a named project champion who has authority to make decisions. Every implementation that starts without these runs longer than it needs to.

How much does a Salesforce implementation cost? See our Salesforce implementation cost guide for a full breakdown by project type, including what drives cost and how to get a useful quote.


If you are planning a Salesforce implementation and want to understand what the timeline looks like for your specific requirements, book a free 30-minute call. We will walk through your scope, flag the variables that will affect timing, and give you a realistic range before you commit to anything.

Free playbook · PDF

10 Automations Every Salesforce Admin Should Build in 2026

Build times, impact ratings, and the exact patterns we use for clients.

Get the playbook

Have a system you'd like us to build?

We turn repetitive work into automations that run in the background — so your team does the work that matters.

Multiply Your Output