What to Expect During a Salesforce Implementation Project
Quick answer: A Salesforce implementation typically runs six phases: discovery and planning, system design, configuration and development, data migration, testing, and go-live with adoption support. A straightforward setup for a small sales team can take four to eight weeks; a multi-department rollout with custom objects, integrations, and legacy data cleanup often runs three to six months. The biggest time and cost swings come from how messy your existing data is and how many systems need to talk to Salesforce.
Key takeaways
Most implementations follow six phases: discovery, design, build, data migration, testing, and go-live — skipping any one of them is the top cause of post-launch rework.
Data migration and cleanup, not configuration, is usually the slowest and most underestimated phase of the whole project.
User adoption training should start weeks before launch, not the day after — Salesforce's own research on CRM adoption points to early, hands-on training as a major factor in whether teams actually use the system.
A simple single-department setup can go live in four to eight weeks; add integrations, custom apps, or multiple business units and expect three to six months or more.
1. Discovery and Planning: Define What "Done" Looks Like
This phase means mapping your current sales, service, or operations process before anyone touches Salesforce configuration. Skip it, and you end up rebuilding your spreadsheet's bad habits inside expensive software.
A good discovery phase answers specific questions: Who uses the system daily? What does a deal or case look like from open to close? What reports does leadership actually pull each week? Which other tools — email marketing, accounting software, a support desk — need to connect to Salesforce?
This is also when you decide which Salesforce edition and licenses fit your team size and budget, since pricing and feature limits vary by tier and change periodically. Confirm current license costs directly with Salesforce or your consulting partner rather than relying on last year's numbers.
Checklist for this phase:
Document your current sales or service process, step by step, before any configuration starts
List every tool that needs to connect to Salesforce (email, marketing automation, accounting, support desk)
Identify 3–5 reports leadership checks regularly so they can be rebuilt in Salesforce
Name a single internal project owner who can make decisions without a committee vote
Set a realistic go-live target date and work backward from it
Don't skip this: The single most common reason implementations run over budget is starting configuration before discovery is finished. Once you've built fields and workflows around an incomplete picture of your process, redoing them costs more than the extra week of planning would have.
2. System Design: Turn the Process Map Into a Blueprint
Design means translating what you learned in discovery into an actual Salesforce architecture — objects, fields, page layouts, and automation rules — before a single click happens in production. Think of it as the blueprint stage of building a house: you don't pour concrete before the drawings are approved.
At this stage, a consultant or admin decides things like:
Whether standard Salesforce objects (Leads, Opportunities, Accounts) cover your needs, or whether you need custom objects for something specific to your business
How records should flow between teams — for example, when a Lead converts to an Opportunity and who gets notified
What automation (flows, approval processes) replaces manual steps your team does today
What each user role should and shouldn't be able to see
If your process is unusual enough that standard Salesforce objects and page layouts don't fit, this is also where the conversation about custom CRM development versus configuring native Salesforce features comes up — a distinction we cover in more depth in Custom CRM Development vs. Salesforce Customization.
3. Configuration and Development: Building the System
This is where the blueprint becomes a working system — building custom fields, page layouts, automation, and any custom code or integrations the design phase called for. Most of this happens in a sandbox, a copy of Salesforce separate from your live production environment, so nothing breaks the system your team is currently using.
Configuration work generally falls into two buckets:
Declarative configuration — fields, page layouts, validation rules, and Flow automation built using Salesforce's built-in tools, no code required
Custom development — Apex code, Lightning components, or third-party integrations for needs that go beyond what standard configuration can handle
Simple implementations may need almost none of the second bucket. Complex ones — say, a business connecting Salesforce to a custom-built inventory system or an AI chatbot — lean heavily on it. If your rollout includes connecting Salesforce to an AI tool for things like automated lead scoring or support ticket routing, that's covered in Dify and Salesforce: Connecting AI Workflows to Your CRM.
4. Data Migration: The Phase Everyone Underestimates
Data migration means moving your existing records — contacts, deals, cases, historical notes — from spreadsheets or your old system into Salesforce in a clean, usable format. This is consistently the phase that takes longer than teams expect, because old data is rarely as clean as people remember it being.
Common problems that surface during migration:
Duplicate contacts or accounts entered under slightly different names
Missing or inconsistent data (some deals have a close date, others don't)
Data trapped in a format the old system exported poorly
Historical records nobody's touched in years but nobody wants to delete either
The fix isn't glamorous: someone has to go through the data, decide what's worth keeping, standardize formats, and map old fields to new ones before import. Budget real time for this — rushing it means importing your old mess into a new system, which defeats much of the point of the project.
5. Testing: Catch Problems Before Your Team Does
Testing means having real users — not just the implementation team — try the system with realistic scenarios before go-live. A consultant clicking through a demo isn't the same as a sales rep trying to log an actual deal with a messy, real-world edge case.
Two kinds of testing matter here:
Testing type | Who does it | What it checks |
Functional testing | Implementation team/admin | Does automation fire correctly? Do fields save? Do reports pull the right numbers? |
User acceptance testing (UAT) | Actual end users | Can a rep complete their daily tasks without getting stuck or confused? |
UAT is the phase teams most often try to shortcut to save time, and it's usually a mistake. Problems that surface here — a confusing layout, a missing field, an automation that fires at the wrong time — are far cheaper to fix now than after 30 people are relying on the system daily.
6. Go-Live and Adoption: The Project Isn't Over at Launch
Go-live means the system becomes the official system of record — but the real test is whether your team actually uses it well in the weeks after. According to Salesforce's own guidance on driving CRM adoption, structured training and visible executive support in the early weeks are strongly linked to whether a rollout sticks or quietly gets abandoned.
Plan for:
A cutover date where the old system (spreadsheet, legacy CRM) stops being updated and Salesforce takes over
Live training sessions for each user group, not just a shared document nobody opens
A short list of "office hours" in the first two weeks where users can ask questions as they hit them
A 30-day check-in to review what's working and what's causing friction
Adoption problems rarely show up as dramatic failures — they show up as reps quietly going back to their old spreadsheet because a field feels confusing or a step feels slower than before. Catching that in week two is far easier than catching it in month six. If you're noticing warning signs like this on a project already underway, 6 Warning Signs a Custom Software Project Is Failing walks through what to watch for.
What This Actually Costs and How Long It Takes
Cost and timeline depend heavily on scope, not just company size — a 10-person sales team with clean data can move faster than a 50-person team migrating from three disconnected systems. For a detailed breakdown by phase, see Salesforce Consulting Costs: A Phase-by-Phase Breakdown.
As a rough shape of what drives timeline:
Single department, standard objects, minimal integrations: several weeks
Multiple departments or custom objects, one or two integrations: a couple of months
Multi-department rollout with custom development, several integrations, and data migration from legacy systems: a few months to half a year
Always confirm current Salesforce licensing costs directly with Salesforce, since pricing tiers are updated periodically.
What to Do Next
If you're at the very start of this process, the highest-value thing you can do this week isn't picking a Salesforce edition — it's writing down your current process, warts and all, and listing every tool that needs to connect to it. That single document shapes every phase that follows.
SFDIFY works with small and mid-size businesses across the country on Salesforce implementations, from initial discovery through go-live and adoption support, alongside custom CRM builds, AI integrations, and app development for teams whose needs go beyond standard configuration. If you're weighing your options or just want a second opinion on scope and timeline, reach out to SFDIFY to talk through where your project stands.
Comments