A focused Salesforce implementation for one team can go live in a few weeks. A Sales and Service Cloud rollout across several teams usually takes two to four months, and a multi-cloud program with ERP integration takes six months or more, delivered in releases. The software is rarely what sets the pace. Scope, data quality, integrations and how quickly your side can make decisions decide the timeline far more than Salesforce does.
How long does a Salesforce implementation take, by project type?
The table below gives the planning ranges we use when scoping work. They are estimates for typical projects, not quotes or guarantees: a project with clean data, a decisive owner and few integrations lands at the short end, and one with messy data, several approvers and an ERP connection lands at the long end or beyond.
| Project type | Typical scope | Planning range | What usually sets the pace |
|---|---|---|---|
| Quick start on one cloud | One team, standard objects, a handful of automations and reports | Days to 2 weeks | How quickly decisions are made; data kept to a minimum |
| Sales Cloud for a sales team | Leads, accounts, opportunities, pipeline stages, forecasting, email and calendar sync | 4 to 8 weeks | Data migration and the number of sales processes to support |
| Sales and Service Cloud together | Sales plus cases, queues, entitlements, knowledge and service reporting | 8 to 14 weeks | Case routing design and the volume of history being moved |
| Migration from another CRM | HubSpot, Dynamics, Zoho, Pipedrive or spreadsheets into Salesforce | 4 to 12 weeks | Record volume, data quality, and whether marketing automation moves too |
| Marketing Cloud or Account Engagement | Journeys, lead scoring, sync with Sales Cloud, consent and compliance | 6 to 16 weeks | Data model for contacts and consent, and content readiness |
| Financial Services Cloud or Health Cloud | Industry data model, households or patients, compliance-aware sharing | 3 to 6 months | Security and compliance review, and custodian or EHR integration |
| Revenue Cloud or CPQ | Products, pricing rules, discount approvals, quote documents, ERP handoff | 3 to 6 months | Pricing complexity and how many product rules exist only in people’s heads |
| Field Service | Work orders, scheduling, mobile app, inventory, technician territories | 3 to 6 months | Scheduling rules, mobile testing in the field, and parts or inventory integration |
| Data 360 | Connecting data sources, identity resolution, segments and activation | 2 to 6 months | The number and cleanliness of source systems |
| A first Agentforce agent | One agent, a few subagents and actions, grounded in your data, with testing | 4 to 12 weeks for a pilot | Knowledge quality, permissions and the evaluation you need before go-live |
| Multi-cloud program with ERP integration | Several clouds, business units and an ERP connection | 6 to 12 months or more, in releases | Integration design, decision speed across business units, and change management |
What did our own projects actually take?
Planning ranges are easier to trust next to real projects. These come from published case studies; each link goes to the full story.
- A multi-region technology-services firm reached a 98% Salesforce health-check score within a 20-hour Jumpstart, because the scope was one cloud and the decisions were made quickly.
- A PE-backed compliance-software company moved from HubSpot to Salesforce in 4 to 6 weeks, with under 8,000 accounts migrated and clear handoffs between marketing and sales.
- A cybersecurity company consolidated an old CRM and a homegrown ticketing system into Sales and Service Cloud, migrating 2,300 accounts and going live with core functionality in roughly 6 to 8 weeks.
- A manufacturer went from zero Salesforce usage to all 99 sales reps working in it within 30 days, with NetSuite integrated, because adoption was planned alongside the build.
Notice what the faster projects have in common: a contained first release, a named decision-maker and data that was cleaned or cut before it moved. None of them tried to deliver every team and every integration at once.
How does company size change the timeline?
Size matters less than scope, but it changes how many people need to agree and how much data moves. These are planning estimates for a core Sales or Service Cloud rollout; add time for each integration and each additional cloud.
| Company profile | Typical first release | Planning range | Where the time goes |
|---|---|---|---|
| Small team, under about 25 users | One cloud, one or two processes, light data migration | 2 to 6 weeks | Decisions and data cleanup; few approvals |
| Mid-size, about 25 to 250 users | One or two clouds, several teams, one or two integrations | 6 to 16 weeks | Agreeing processes across teams, integration testing, training by role |
| Larger or multi-unit, over about 250 users | Several clouds or business units, ERP integration, governance | 4 to 12 months, in releases | Cross-unit design decisions, security reviews, change management and staged rollout |
A large company can still go live quickly with a narrow first release, and a small company can take months if it tries to connect every system at once. Scope the first release to what one team needs, prove it, then expand.
Where do the weeks go, phase by phase?
Every Salesforce implementation moves through the same phases, whatever the cloud. The table shows how a typical 12-week Sales and Service Cloud project splits its time. Shorter projects compress each phase; longer programs repeat build, test and launch for each release.
| Phase | Share of the project | Weeks in a 12-week project | What you should hold at the end |
|---|---|---|---|
| Discovery | About 15% | Weeks 1 and 2 | Written, prioritized requirements, process maps, a data inventory and an integration list |
| Design | About 15% | Weeks 2 and 3 | An agreed data model, security and sharing design, automation and integration designs |
| Build | About 35% | Weeks 4 to 8 | A configured sandbox, integrations working end to end, test scripts written |
| Testing and user acceptance | About 15% | Weeks 8 to 10 | Defects fixed, real users have signed off real scenarios, data migration rehearsed |
| Launch | About 10% | Weeks 10 and 11 | Data migrated, users trained by role, go-live completed |
| Hypercare | About 10%, often longer | Weeks 11 and 12 and beyond | Fast fixes, adoption tracking, and a handover or managed-services plan |
Two patterns matter here. First, phases overlap: design starts before discovery is fully closed, and data preparation runs alongside the build. Second, testing and hypercare are where squeezed schedules do the most damage. A plan that gives user acceptance testing a few days instead of a couple of weeks is not faster; it moves the defects into production.
What are the seven factors that set your Salesforce timeline?
When two projects with the same cloud take very different amounts of time, the difference almost always comes from these seven factors.
1. How much goes live at once
Each additional team, business unit or cloud in the first release multiplies the design decisions, the testing and the training. A first release scoped to one team and one cloud can go live in weeks; the same work across four business units with different processes takes months, because every shared object and report needs agreement.
2. The state of your data
Data work is the most common source of surprise. Duplicate accounts, inconsistent picklist values, missing owners and years of history nobody uses all have to be dealt with before migration, not after. The faster projects decide early what to leave behind, clean what remains in the source system, and rehearse the migration at least once.
3. The number and type of integrations
Every connected system adds design, build and testing time, and some add a second team’s calendar. Connecting email and calendar is quick. Connecting an ERP for orders, pricing or invoices usually depends on the ERP team’s availability, test environments and approvals, which often become the critical path.
4. How fast your side can make decisions
Implementation partners can only build what has been decided. If process questions wait a week for a steering meeting, or several stakeholders each hold a veto, the build stalls. A named business owner with authority, and a standing weekly decision slot, does more for the timeline than adding consultants.
5. Configuration versus custom code
Standard objects, Flow and page layouts cover most requirements and are fast to build and change. Custom Apex or Lightning Web Components take longer to design, build, test and maintain. Custom work is sometimes the right answer, but every piece of it should earn its place against a real process need.
6. Security, compliance and procurement reviews
Regulated industries and larger companies often need security questionnaires, data-residency checks, single sign-on setup and change-advisory approvals. None of these is hard, but each has its own queue. Starting them in week one rather than week eight can save a month.
7. The availability of your people
Discovery workshops, design reviews and user acceptance testing all need time from the people who run the business. When those people cannot step away from their day jobs, sessions slip and testing gets rushed. Book testers and workshop attendees when the project is approved, not when the phase starts.
What makes Salesforce implementations run late?
Delays rarely come from one dramatic failure. They come from small slips that compound. These are the ones we see most:
- Discovery that produced meeting notes rather than written requirements, so design keeps reopening settled questions.
- Data problems found during migration rehearsal instead of during discovery.
- An integration that depends on another team or vendor whose calendar was never confirmed.
- Scope added through informal requests rather than a visible change process, so the plan never updates.
- User acceptance testers who are not available when testing starts.
- Security or compliance reviews started late, after the build is done.
- Approvals that need several people, none of whom can decide alone.
- A big-bang launch for a program that should have been released in stages.
How can you shorten a Salesforce implementation without cutting corners?
Shorter is only better if the result still works and people use it. These approaches reduce the calendar time without moving risk into production:
- Scope a first release around one team and its most important process, and put everything else on a written backlog for the next release.
- Decide your data cutoff early: how many years of history move, which records are archived, and which fields are dropped.
- Clean data in the source system while the build is under way, so migration is a load rather than a cleanup.
- Name one decision owner per area and hold a fixed weekly decision meeting.
- Use standard Salesforce features first and agree that custom code needs a stated reason.
- Run data preparation, integration work and training material in parallel with the build rather than after it.
- Book user acceptance testers and trainers when the project is approved.
- Start security, single sign-on and compliance reviews in the first week.
What should you prepare in the two weeks before kickoff?
The fastest projects are often won before the partner starts. Two weeks of preparation on your side can remove most of the early delays:
- Name the executive sponsor and a business owner for each team in scope, and put a weekly decision meeting in their calendars.
- List every system Salesforce must connect to, with an owner and a contact for each.
- Export a sample of the data you plan to move, and note the obvious problems: duplicates, missing owners, inconsistent values.
- Collect the reports and spreadsheets each team really uses, not the ones they say they use.
- Book the people who will attend discovery workshops and the people who will test, with dates.
- Send the security, procurement or compliance questionnaires your company requires, so their clocks start now.
- Agree the two or three outcomes that will tell you the project worked.
Our guide to preparing for Salesforce discovery covers this preparation in more depth, including what to bring to each workshop.
Should you protect the date or the scope?
When a project comes under pressure, something has to give: the date, the scope or the quality. Quality is the wrong thing to cut, because defects found by users after launch cost more and damage trust. Decide early which of date and scope matters more. If a date is fixed by a contract renewal, a busy season or a board commitment, protect it by moving lower-priority scope into a second release. If the scope is non-negotiable, for example a regulatory requirement, protect it by letting the date move and saying so early. A partner who will not have this conversation with you is a risk in itself.
What does a week-by-week plan look like for a 12-week project?
This is an illustrative plan for a Sales and Service Cloud rollout to two teams with one integration and a migration from another CRM. Your plan will differ, but a partner’s plan should be at least this specific.
- Week 1: kickoff, stakeholder interviews, current-process walkthroughs, data and integration inventory, security review started.
- Week 2: process workshops for sales and service, draft requirements, data cutoff decided, success measures agreed.
- Week 3: data model, sharing and security design, automation and integration designs reviewed and signed off.
- Weeks 4 and 5: core configuration in a sandbox, first data load to the sandbox, integration build started.
- Weeks 6 and 7: automation, reports and dashboards, integration testing, training materials drafted.
- Week 8: system testing and defect fixing, second migration rehearsal.
- Weeks 9 and 10: user acceptance testing with real users and real scenarios, sign-off, cutover plan agreed.
- Week 11: final data migration, role-based training, go-live.
- Week 12 onward: hypercare with daily triage, adoption dashboards reviewed, handover or managed services begin.
How long does a Salesforce data migration take?
For most small and mid-size companies, the migration itself is a weekend or less; the preparation around it is what takes weeks. Expect to spend time mapping fields, cleaning and de-duplicating records, deciding how much history to move, and running at least one full rehearsal into a sandbox. Large volumes, attachments and complex relationships between objects extend this. Plan a short freeze on the old system during cutover so records created during the move are not lost.
How long does an Agentforce implementation take?
A first agent with a narrow job, a few subagents and actions, and good knowledge content can reach a pilot in a few weeks. The time goes into preparing the data and knowledge the agent relies on, setting permissions so it can only see and do what it should, and testing it against real conversations before customers or staff use it. Expanding from a pilot to several agents across teams is a program, not a project, and is best planned in releases.
How do you judge a partner’s proposed timeline?
A timeline in a proposal tells you a lot about how a partner works. Look for these signs of a plan that will hold:
- Phases with named deliverables, not just dates.
- Your responsibilities written down: decisions, data, testers and approvals, with dates.
- Assumptions listed, such as the number of integrations, data volume and how many users are in scope.
- Real time for user acceptance testing and for hypercare after launch.
- A change process that shows how new requests affect the date.
- A release plan for anything multi-cloud or multi-team, instead of one big launch.
Be cautious about a fixed date given before discovery, a plan with no time for your people to test, or a multi-cloud program promised in a single release. These are the plans that slip.
When does Salesforce start paying off after go-live?
Go-live is the start of the value, not the end of the project. The first few weeks after launch decide whether people keep using Salesforce or drift back to spreadsheets. Plan hypercare, track adoption by team, fix friction quickly and keep a small backlog moving. The manufacturer above reached full adoption by 99 reps in 30 days because adoption was treated as part of the project, not as an afterthought.
Frequently asked questions about Salesforce implementation timelines
Can Salesforce be implemented in a month?
Yes, for a contained scope: one team, standard functionality, limited data and few integrations. Several of the projects above went live in four to eight weeks. A month is not realistic for multi-cloud programs, heavy custom development or complex ERP integration.
Does adding more consultants make the project faster?
Only up to a point. Most delays come from decisions, data and availability on the client side, and more consultants do not fix those. Beyond a right-sized team, adding people adds coordination time.
How long should hypercare last?
Two to four weeks is common for a single-cloud rollout, longer for multi-cloud or field-based teams. Hypercare should end with a clear handover: to an in-house admin, to managed services, or to a planned next release.
Is it faster to start with a pilot?
Usually. A pilot with one team proves the design with real users, surfaces data problems early and builds internal support. The rollout to other teams then goes faster because the core is already tested.
What is the difference between go-live and done?
Go-live is the day people start working in Salesforce. Done is when the outcomes you agreed at the start are being met and the system has an owner. Between the two sit hypercare, adoption work and usually a second release. Plan the budget and the calendar for both.
Who should own the timeline on our side?
One person: usually a project lead who reports to the executive sponsor. They own your side’s commitments, such as decisions, data, testers and approvals, and meet the partner’s project manager every week. Without that role, the partner’s plan depends on commitments nobody on your side is tracking.
