Ask three vendors how long a Salesforce implementation takes and you might hear “a few weeks,” “about 4 months,” and “it depends.” All three can be right. Basic setups run 6 to 12 weeks, mid-market builds 3 to 5 months, and multi-cloud programs 4 to 8 months or more. This guide covers the benchmarks by size, the phase-by-phase timeline, what stretches a schedule, and what happens after launch. For a scoped estimate, see VALiNTRY360’s Salesforce implementation services.
The Short Answer by Project Size
Published benchmarks vary by source, but they cluster closely enough to plan around.
A basic single-cloud setup, with standard objects, a small user group, and light automation, usually takes 6 to 12 weeks. A mid-market implementation with custom workflows, a couple of integrations, and a real data migration runs 3 to 5 months. Multi-cloud builds, such as Sales Cloud plus Service Cloud plus Marketing Cloud, land between 4 and 8 months, and some enterprise programs stretch toward a year.
Fixing an org that already exists runs on a different clock. Cleanup and rescue projects, where the goal is repairing automation, cleaning data, or rebuilding adoption, usually take 4 to 12 weeks.
Treat all of these as planning ranges. Your own Salesforce implementation timeline depends on what you’re connecting and how clean your data is.
Where the Weeks Actually Go
A common breakdown uses 8 implementation phases, and vendor benchmarks put them at roughly these lengths:
- Discovery: 2 to 4 weeks
- Solution design: 2 to 3 weeks
- Configuration: 3 to 6 weeks
- Data migration: 2 to 4 weeks
- Integrations: 2 to 6 weeks
- Testing and user acceptance: 2 to 3 weeks
- Training: 1 to 2 weeks
- Go-live: 1 to 2 weeks
Add those up and you’d get 15 to 30 weeks, which sounds longer than the mid-market range above. The reason is overlap. Data migration usually starts while configuration is still underway, and training prep runs alongside testing. A good project plan shows those overlaps on a calendar, so ask to see one before kickoff.
Discovery is the phase teams most want to shorten, and it’s usually the wrong one to cut. Requirements missed there tend to come back as rework during testing, when changes cost more. Training deserves a second look too. With a few dozen users or more, rolling it out team by team often works better than one big session.
The Delays Nobody Puts in the Proposal
Data is one of the most common sources of delay. Duplicates, missing fields, and records from a retired system need cleanup before they can load, and that work tends to surface late. VALiNTRY360’s migration for Real California Milk moved the team from SugarCRM to Sales Cloud with automated imports, and manual data-update work dropped from 500 hours a year to 4. The case study walks through that migration.
Integrations come next. Connecting an ERP or finance system often takes more calendar time than configuring Salesforce itself, because it depends on another team’s schedule and another system’s quirks. Each connection also needs its own test cycle, so the timeline grows with every system you add.
Then there’s decision speed. A project waiting 2 weeks on a sign-off loses 2 weeks, no matter how fast the build team moves.
What Keeps a Project on Schedule
Faster projects fix the scope before configuration begins, so new requests go to a later phase instead of the current one. Anything that arrives mid-build waits its turn, which keeps the original dates intact.
Rollout strategy matters too. A big-bang launch ends sooner on paper, but a phased rollout puts a working system in front of one team first, so problems show up while they’re still small. If your org has several departments with different processes, phasing often finishes with fewer surprises, even when the calendar runs longer.
Custom code is the other lever. Standard Salesforce features ship faster than custom Apex or Lightning components, and they’re easier to maintain through the platform’s 3 yearly releases.
What Your Own Team Owes the Project
Partners control the build. You control the pace of everything around it. Business owners need to attend discovery workshops and answer questions within a day or two. Someone who knows your data has to explain what each old field means before it migrates. Power users need protected hours for user acceptance testing.
When those hours go missing, the schedule slips, and the partner takes the blame for a delay on your side of the table. Ask your Salesforce implementation partner for a weekly hours estimate per role at kickoff, then hold your team to it.
Does the Clock Stop at Go-Live?
Not quite. Hypercare windows commonly run 30 to 90 days, though some partners plan as little as 2 to 4 weeks. During that stretch the build team stays close to your users and fixes issues as they surface. Ask where hypercare starts and ends in the contract, since it sometimes sits outside the base quote. Skip it and small bugs linger while adoption drops.
Budget time for a second phase as well. Reports people request after seeing real data, extra automation, and training refreshers tend to show up within the first quarter. Planning for them up front keeps them from looking like overruns later.
How to Build a Timeline You Can Trust
Ask any partner for a phase plan with dates, owners, and dependencies instead of a single end date. Compare it against the ranges above. A 6-week promise for a multi-system build is worth questioning, and it’s fine to check a firm’s track record in Salesforce’s AppExchange consultant directory before you commit. Then pad the phases that tend to slip, usually data and integrations.
