A Salesforce implementation has five phases: discovery, design, build, launch and stabilization. Timelines depend mostly on scope, data quality and integrations, not on Salesforce itself. A focused single-cloud setup can go live in days or weeks; multi-cloud programs with ERP integration and several business units take months. The most reliable predictor of success is how clearly requirements and decisions are owned before building starts.
The five phases
| Phase | What happens | What you should have at the end |
|---|---|---|
| 1. Discovery | Workshops with the people who will use the system; review of current tools, data and reports | A written scope with priorities, users, integrations and success measures |
| 2. Design | Data model, security and sharing, automation and integration design | Agreed designs signed off before anything is built |
| 3. Build | Configuration in a sandbox, custom code only where needed, integrations, test scripts | A working org tested against real scenarios |
| 4. Launch | Data migration, role-based training, go-live and hypercare | Users working in Salesforce with support on hand |
| 5. Stabilize | Fixes, adoption tracking, handover or managed services | An org the business trusts and a plan for what comes next |
What drives the timeline
- Scope: the number of clouds, teams and processes going live at once.
- Data: how much history is moving, and how clean it is.
- Integrations: each connected system adds design, build and testing time.
- Decisions: how quickly someone with authority can settle process questions.
- Customization: configuration is faster to build and maintain than custom code.
Real examples from our own work show the range. A multi-region technology-services firm went fully live on Sales Cloud within a 20-hour Jumpstart and scored 98% on a Salesforce health check. A compliance-software company moved from HubSpot to Salesforce in 4–6 weeks, including marketing automation. A cybersecurity company consolidated an old CRM and a homegrown ticketing system into Sales and Service Cloud, migrating 2,300 accounts in 6–8 weeks.
Configure first, customize only when it earns its keep
Standard objects, Flow and page layouts cover most requirements and are cheaper to maintain. Custom Apex or Lightning Web Components make sense when configuration cannot model the process; a broker-dealer we worked with needed custom objects for both sides of capital-raising deals. The test is whether the next admin could maintain it.
Pre-implementation checklist
Use this before you sign a statement of work, whoever your partner is:
- A named business owner who can make process decisions, with time set aside for the project.
- Two or three success measures, such as adoption, pipeline visibility or case handling time.
- A list of every system Salesforce must connect to, with an owner for each.
- An inventory of the data you plan to move, and a decision about what to leave behind.
- Users from each team available for discovery workshops and testing.
- A training plan by role, not a single all-hands demo.
- A plan for after go-live: in-house admin, managed services, or both.
How to choose an implementation partner
- Ask for case studies in your industry and with the clouds you are buying.
- Ask who will actually do the work, and whether they are onshore or offshore.
- Ask how they handle data migration and what reconciliation looks like.
- Ask what happens after go-live and how support is priced.
- Ask for a written scope before a price; a price without a scope is a guess.
Who does what on each side of a Salesforce implementation?
The partner designs and builds; the client decides, supplies data and tests. Projects stall when a task falls between the two and nobody claims it.
| Role | Usually filled by | Owns |
|---|---|---|
| Executive sponsor | Client | Budget, priorities and the final call when owners disagree |
| Business owner | Client | Process decisions and sign-off on designs and test results |
| Subject-matter experts | Client | How the work really happens, including the exceptions |
| Data owner | Client | Source extracts, cleanup choices and sign-off on reconciled loads |
| Future admin | Client | Learning the build as it happens, then running it after launch |
| Project manager | Both, one on each side | Plan, risks, dependencies and status reporting |
| Solution architect | Partner | Data model, security and integration design |
| Consultants and developers | Partner | Configuration, code, integrations and support during testing |
The future admin is the role most often forgotten. Invite them to design reviews and build demos, not only to training at the end.
How should you run discovery workshops?
Organize workshops around processes rather than departments, and invite the people who do the work. Every session should end with written decisions and a list of open questions.
- Send an agenda naming one process, such as lead to opportunity, and ask attendees to bring real examples.
- Walk through recent records from start to finish, including ones that went wrong.
- Ask what each step decides, who needs to know, and which report depends on it.
- Capture exceptions on a separate list, then ask how often each one really happens.
- Keep managers and front-line staff in the same session, so the process described matches the process followed.
- Circulate notes quickly and ask for corrections while the discussion is still fresh.
What is a decision log, and why keep one?
A decision log is a shared record of each design choice, who made it and why. It stops settled questions from being reopened and shows newcomers how the org got its shape.
Each entry needs a short description, the options considered, the choice made, the owner and the date. Link it to the requirement it answers. When a new request arrives, check the log first. If the request overturns a logged decision, send it through change control instead of a quick chat with a consultant.
How do you know each phase is really finished?
Agree exit criteria for every phase before it starts, and have the business owner sign them off. A phase ends when its criteria are met, not when its calendar slot runs out.
| Phase | Finished when | Gap to watch for |
|---|---|---|
| Discovery | Scope, priorities and the out-of-scope list are signed, and every integration has a named owner | Exceptions described in workshops but never written down |
| Design | Data model, security and automation designs are approved, and no open decision blocks the build | Sharing and visibility rules left until build is underway |
| Build | Every requirement maps to a configured item and a test script, and a sandbox demo is accepted | Tests run only with invented sample data instead of real records |
Launch and stabilization have their own readiness and handover criteria, which our go-live checklist covers in detail.
