← Blog · Salesforce

What to Expect During a Salesforce Implementation Project

What to expect in a Salesforce implementation: the six phases from discovery to go-live, why data migration takes longest, and how to drive user adoption.

Akmammet Allakgayev · Founder & publisher, SFDIFY
Researched and drafted with AI from the cited sources · how we check
Published Updated 8 min read
What to Expect During a Salesforce Implementation Project
Photo: Lukas Blazek on Pexels
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. Salesforce's own implementation guide says a small business can be up and running in a few weeks, while larger enterprises with intricate integrations might require several months [1]. 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 (Salesforce's own guide splits the same work into nine steps, from needs assessment to evaluation [1]) — skipping any one of them is a common cause of post-launch rework.
  • Data migration and cleanup, not configuration, is usually the slowest and most underestimated phase of the whole project; Salesforce lists data migration issues among the common implementation challenges [1].
  • User adoption training should start weeks before launch, not the day after — Salesforce's own implementation guidance says proper training minimizes resistance to change and boosts adoption rates [1].
  • A simple small-business setup can go live in a few weeks; add intricate integrations, custom apps, or multiple business units and expect several months [1].

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 — for example, Salesforce raised Enterprise and Unlimited Edition list prices by an average of 6% on August 1, 2025 [2]. 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

Salesforce lists scope creep and poor planning among the common implementation challenges [1], and starting configuration before discovery is finished is a fast route to both. 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, an isolated copy of your production environment, so nothing breaks the system your team is currently using [3].

Configuration work generally falls into two buckets:

  • Declarative configuration — fields, page layouts, validation rules, and automation built with Flow Builder, which creates automation that runs when a record is created, edited, or deleted [4]
  • Custom development — Apex (Salesforce's Java-like programming language), Lightning components built with HTML and JavaScript, or third-party integrations for needs that go beyond what standard configuration can handle [4, 5]

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, remove duplicates, decide what's worth keeping, standardize formats, and map old fields to new ones before import [6]. 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 checking the system thoroughly before go-live, including user permissions, workflow automations and migrated data, and trying any AI agents in real workflows with a small pilot group before scaling more broadly [1], ideally in a sandbox, since testing in production is high risk [3]. In our experience, that testing should include real users, not just the implementation team. 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. Salesforce's own implementation guide says proper training boosts adoption rates, and that getting past rollout problems takes clear communication, strong leadership, and ongoing support [1].

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

Timeline depends heavily on business size, workflow complexity, and customization needs [1], and cost tends to follow the same drivers — 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.

In our experience, as a rough shape of what drives timeline:

  • Small business, single department, standard objects, minimal integrations: a few weeks [1]
  • Multiple departments or custom objects, one or two integrations: a couple of months
  • Larger, multi-department rollout with intricate integrations, custom development, and legacy data migration: several months [1]

Always confirm current Salesforce licensing costs directly with Salesforce, since list prices do change — for example, the average 6% Enterprise and Unlimited Edition increase on August 1, 2025 [2].

How SFDIFY can help: SFDIFY is a Salesforce Consulting Partner for implementations, custom development and integrations. See our Salesforce consulting services.

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 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.

Sources

  1. CRM Implementation: A Comprehensive 9 Step Guide — checked 2026-11-08
  2. Salesforce Announces Pricing Update — checked 2026-11-08
  3. Salesforce Sandboxes: Sandbox Development Environment — checked 2026-11-08
  4. Get Started with Business Process Automation (Trailhead) — checked 2026-11-08
  5. Get Started with Apex (Trailhead) — checked 2026-11-08
  6. Import Data (Trailhead) — checked 2026-11-08

Related

Want a product built this way?

Tell us what you are building.

Start a Project