Salesforce Implementation Timeline: How Long It Takes by Project Size

Ask Google how long a Salesforce implementation takes and page one will tell you three to four weeks. It will also tell you two weeks to over a year. A consultancy post from September 2026 says four to eight weeks for a small business. Another from December 2025 says six to twelve months for an enterprise. Salesforce’s own CRM implementation guide answers the question with “a few weeks” for small businesses and “several months” for larger ones.

Every one of those answers is defensible. None of them is useful, because not one states the assumptions that make it true.

A duration band without its assumptions is a horoscope. This page gives the bands, then gives the three mechanisms that decide which band you land in, because the mechanisms are what you can actually act on.

Three clocks set a Salesforce go-live date, and delivery owns one

Elapsed time on a Salesforce project is not one quantity. It is three independent clocks running at the same time, and the longest one sets your date.

Almost every published timeline models the first clock and ignores the other two. That is why estimates feel reasonable at kickoff and wrong by week six. The build clock is the one a delivery team measures, improves and reports on, so it is the one that gets attention, while the two clocks that routinely add more weeks go unmanaged.

A date is credible only when all three have been estimated separately. Running them together into a single number is the error that produces the twelve-week project that lands in month seven.

Effort divided by parallelism caps how fast the build clock can run

Effort and duration get conflated constantly. They are different quantities with a divisor between them.

Six hundred hours of configuration does not take six hundred hours of calendar. It takes six hundred divided by however much of that work can proceed at once, and Salesforce work resists parallelism in specific places. The data model has to settle before automation is built on it. Sharing has to be decided before anything that depends on record visibility. Integration contracts have to be agreed before either side builds against them.

So adding people compresses the parts that are independent and does nothing for the parts that are sequential. Two developers building two unrelated objects halve that work. Two developers waiting on the same data model decision halve nothing.

Testing behaves the same way. User acceptance testing cannot start before a build is stable, cannot compress below the client’s availability to test, and produces defects that need a fix-and-retest loop nobody schedules. That loop is where build-clock estimates most often break, and the mechanics of running it tightly are covered in the Salesforce UAT guide.

How the effort figure itself should be derived, and how to defend it when challenged, is a separate discipline set out in a defensible estimation method. This page assumes you have a credible effort number and asks what happens to it on a calendar.

Client approval speed shapes the calendar more than build speed does

Here is the clock nobody prices. Every Salesforce project contains a queue of decisions that only the client can make, and the time those decisions spend waiting is pure calendar with no effort attached.

Which fields are mandatory. Who sees whose records. Whether the legacy status values map or get rationalized. Who signs off on the migration. Which of two conflicting regional processes wins.

That last category is the expensive one. A decision requiring agreement between two business units does not wait on an individual, it waits on a meeting that has to be convened, and a fortnight passes without anyone doing anything wrong.

Three properties of this clock matter for planning.

It is invisible in effort-based plans, because waiting consumes no hours. A Gantt chart showing continuous work implies decisions arrive instantly, which they never do.

It compounds through dependencies. A sharing model decision delayed two weeks does not cost two weeks; it costs two weeks plus everything downstream that could not start, which is why a single unanswered question can move a go-live date by a month.

It is measurable in advance. Ask during discovery how long the client’s last comparable sign-off took, who holds authority, and what happens when two departments disagree. An organization that took six weeks to approve a field naming convention will not approve a sharing model in three days.

The mitigation is unglamorous and works. Name every decision, name one accountable owner, set a date by which silence counts as acceptance of the proposed default, and review the open list weekly with the sponsor in the room.

Salesforce security enforcement reached sandboxes before production through 2026

The platform clock is the one that surprises people, and 2026 gave an unusually clear demonstration of it.

Salesforce rolled out a sequence of mandatory security changes under what its documentation calls Security-Related Product Updates to the Salesforce Platform. Salesforce Ben’s roadmap of the rollout, published in May 2026 and updated through June, tracked the enforcement dates as they firmed up.

Read the columns in order, because the pattern is the point. Every change reached sandboxes before production, by nine days to four weeks. A sandbox is where a project under construction lives. So platform-mandated change arrives in the project environment first, while the client’s live org is still untouched, and a build team can lose days to an authentication change the client has not yet experienced and will not accept as a real cause of delay.

One row lands harder on the delivery team than on the client. The phishing-resistant requirement reaches anyone holding the System Administrator profile, Modify All Data, View All Data, Customize Application or Author Apex. Those last two sit with every developer and consultant on a build, so the people hit first are the project team rather than the client’s admins, and the acceptable methods narrowed to built-in authenticators such as Windows Hello or Touch ID and physical security keys such as a YubiKey. A team with no hardware keys in a drawer finds that out mid-sprint.

Dates in a rollout this size also move. Reporting through July indicated the schedule was paused and then resumed, with later waves running by release group into September, so treat the table as the position at the source’s June update rather than a fixed calendar.

Practitioner reaction captures the compression better than any vendor summary. A thread on r/salesforce in June 2026 drew more than seventy comments, describing the changes as squeezed into roughly twelve weeks between April and July, and singling out an authentication scheme change for apps using OAuth that arrived with about eight weeks of notice.

None of that is a criticism of the security work, which was overdue. It is an illustration of a planning rule: a Salesforce project running longer than a quarter will intersect at least one dated platform change, and the only protection is to check Salesforce’s published update schedule before committing to a go-live date rather than after.

GetGenerative.ai agents compress the build clock and leave two untouched

Any honest claim about AI and project duration has to say which clock it affects. Most do not, which is why buyers have learned to discount them.

GetGenerative.ai runs six agents across the delivery lifecycle, and their effect lands almost entirely on the build clock, in the specific part of it that consists of producing artifacts rather than configuring Salesforce.

Trace a week of a Salesforce project and a surprising amount of it is writing. Workshop notes become requirements. Requirements become a design. The design becomes stories with acceptance criteria. Stories become test scripts. Each handoff waits on the person before it, and on a small team that person is usually the architect or lead consultant with three other claims on their day.

Discovery, Design, Metadata and Testing each take one of those handoffs. Workshops arrive as structured scope with a schedule and resourcing attached. Designs get written against metadata pulled from the live org instead of against recollection. Test scripts appear alongside the stories rather than in the week before testing opens.

What changes on the calendar is the queue, not the typing speed. Writing that previously waited for a senior person to find an afternoon now waits only for that person to review it, and review is faster than authorship. That shortens the critical path in a way hiring a junior developer does not.

What agents cannot do deserves equal billing. They cannot make a client decide faster. They cannot move a Salesforce enforcement date. A proposal claiming AI will halve a twelve-week project is claiming something about all three clocks while only affecting one, and any buyer who has run an implementation will test that claim. Teams weighing the platform against a delivery date can see how an agent-led delivery is scoped.

Data migration consumes calendar in cycles, not in a single pass

Migration gets planned as a task and behaves as a loop, which makes it the most reliably underestimated item on any Salesforce schedule.

The first load exposes data problems nobody knew about. Duplicate accounts under different spellings. Required fields empty across years of records. Picklist values that exist in the source and nowhere in the target. Owners who left the company. Each discovery sends work back to the client, who has to decide what the correct value is, which puts migration on the decision clock as well as the build clock.

Three cycles is a realistic plan for anything beyond a simple contact list: a first load to surface problems, a second after cleansing to validate the mapping, and a rehearsal against the real cutover sequence. Teams that budget one pass are planning for an outcome that occurs when the source data is already clean, which is rare enough that it should be treated as an assumption to verify rather than a default.

Volume matters less than variety here. A million clean rows from one system loads faster than eighty thousand rows from four systems with inconsistent customer identifiers, because the second case needs reconciliation logic and a human to arbitrate conflicts.

Duration bands hold only with their assumptions attached

Here are the bands. They are useful only alongside the conditions beneath them, which is the part most published tables omit.

Three conditions sit behind the whole table. A named sponsor with decision authority who attends a weekly review. Source data that has been profiled before kickoff rather than discovered during migration. A scope baseline with a change process, since an unmanaged change queue defeats any band in the table.

Remove any one of those and the project moves to the row below. Remove two and the band stops predicting anything. What those months cost, as distinct from how long they run, is broken down in what those months cost to run, and the phase structure inside each band is laid out in the phase-by-phase implementation plan.

Salesforce’s own guidance adds a caveat worth repeating, because it comes from the vendor and not from a critic. Its CRM implementation guide notes that incorporating AI features and testing AI agents may extend the timeline. Agent work adds a testing and tuning cycle that configuration does not need, and a plan that treats an Agentforce deployment as equivalent to a Flow build has mispriced the calendar.

Compression levers rank by effect, and proposals usually pull the weakest

Asked to shorten a timeline, most teams reach for more developers. That is close to the least effective option available.

Ranked by actual effect on elapsed time:

Cut scope. Nothing else is close. Deferring one integration or one reporting suite removes work, dependencies and decisions together.

Pre-decide the decisions. Running discovery to the point where the sharing model, data model and integration contracts are settled before the build starts removes the decision clock from the critical path, where it does the most damage.

Profile the data before kickoff. Converting migration surprises into known work is worth more weeks than any staffing change.

Shift artifact production to agents. Real, bounded, and confined to the build clock.

Add people. Works only on truly parallel work, and carries onboarding cost that can make a short project longer.

Shorten testing. Not a compression lever. It relocates the delay to hypercare, where it costs more and is more visible to the client.

Phasing deserves separate mention because it is often the honest answer. Two releases of eight weeks will usually beat one release of sixteen, not because the work shrinks, but because the first release puts the system in front of real users while the second is still cheap to change.

A date slipping leaves three honest responses

When a date stops being achievable, three options exist, and pretending otherwise is a fourth that always costs more.

Cut scope to hold the date. Right when an external commitment, a fiscal boundary or a contract renewal depends on going live, and acceptable when the deferred items are truly deferrable.

Move the date and re-baseline. Correct when the date was arbitrary and quality matters more than the calendar. Do it once, with a new plan, rather than in a sequence of two-week slips that destroys the sponsor’s confidence.

Go live partially. Right when one user group or region can start while another waits, which also shortens feedback loops on everything still to come.

The option that is never right is holding the date and absorbing the gap silently by compressing testing. That converts a schedule problem into a quality problem, moves it past go-live where it is more expensive, and is one of the recurring patterns behind the nine causes of failed Salesforce programs. Cutover mechanics for whichever option you choose belong in the go-live checklist.

Dates get questioned in six predictable ways

How long does a Salesforce implementation take?

A single cloud with light customization for around 60 users typically runs 12 to 16 weeks from kickoff to go-live. Small out-of-box rollouts under 25 users can finish in 4 to 8 weeks. Multi-cloud or regulated enterprise programs run 9 to 18 months. Each band assumes a sponsor with decision authority, data profiled before kickoff, and a managed change process.

Why do published Salesforce timelines disagree so much?

Because almost none of them state their assumptions. Search results for this question currently range from three to four weeks to over a year, and both ends are accurate for the projects their authors had in mind. A duration figure only transfers to your project if the integration count, migration complexity, approval structure and customization level are comparable.

What delays Salesforce implementations most often?

Client decision time, not build time. Approvals on sharing models, field requirements and data mapping consume calendar without consuming effort, and they compound because downstream work cannot start. Data migration is second, because it runs in cycles rather than a single pass.

Can AI agents shorten a Salesforce implementation?

They shorten the part of the build clock spent producing artifacts such as stories, designs, test cases and documentation, which is a real share of elapsed time on a small team. They cannot speed up client decisions or move platform enforcement dates. Salesforce also notes that testing AI agents may extend a timeline, so agent scope adds calendar even while agent tooling removes some.

Do Salesforce platform changes affect project schedules?

Yes, and they reach sandboxes before production. Through mid-2026 Salesforce enforced several mandatory security changes in sandboxes two to five weeks ahead of production orgs, so project teams encountered them before clients did. Any project running longer than a quarter should check Salesforce’s published update schedule before a go-live date is committed.

Does adding developers shorten a Salesforce project?

Only for work that can actually run in parallel. Sequential dependencies, such as the data model settling before automation or sharing being decided before visibility-dependent features, do not compress with headcount. Cutting scope and pre-deciding open decisions both outperform adding people.