Salesforce Implementation Checklist: 8 Phases (2026)

What are the eight phases of a Salesforce implementation?

Here is the whole plan on one page. Each phase has its own section below, with numbered steps.

Most failures start in phase 1 or 2, before anyone builds anything. Vague goals, weak ownership, unclean data and too much custom code are the usual causes.

Adding AI to the rollout? If you plan to use Agentforce or any AI agent, run an Agentforce readiness audit before kickoff. It checks whether your data quality, permissions and flows can support agents.

Regulated industry? Healthcare, finance and government teams should map each compliance control to a Salesforce setting early, because late fixes mean rework.

How do you plan a Salesforce implementation?

Planning decides most of the outcome. Do these steps before you create a single user.

1. Write three to five goals that a number can prove or disprove. A weak goal is "implement Salesforce for sales". A strong goal is "raise the Lead to Opportunity conversion rate and cut manual data entry for every seller, with a target for each".
2. Name one owner for each goal. Give the owner the right to decide, not only to be informed.
3. Build a RACI chart (Responsible, Accountable, Consulted, Informed) for every phase. The Accountable person approves the work. The Responsible person does it.
4. Book a weekly sprint review with the key stakeholders. They see progress early and flag problems before launch.
5. List your budget lines: licenses, partner services, data migration, integrations, training, and the admin time after launch. Add a buffer to both budget and timeline. For real numbers, read the Salesforce implementation cost guide.
6. Pick your edition and count your licenses. Check the current prices on the Salesforce Sales Cloud pricing page, because they change.

Done when: every goal has an owner, a number and a date, and the budget has a buffer line. If it slips: pause the build until the owner list is complete. Nothing in Salesforce is hard to undo yet.

How do you capture requirements without over-building?

Map how people work today, then decide what Salesforce needs to change. The rule is configure before you customize. Configuration means clicks in Setup, such as fields, page layouts and Flow. Customization means code, such as Apex.

1. Interview your best sellers and support agents. Watch their real work, because documented processes often differ from actual work.
2. Write down each current process: lead intake, qualification, quoting, handoff to service and renewals.
3. List every system that must connect to Salesforce, with a named owner for each.
4. Mark each requirement as standard, configurable or code. Choose standard first.
5. Score each custom request on business impact, build effort and upkeep. Drop the ones with no clear business case.
6. Open Setup > Object Manager and list the standard objects you will use (Account, Contact, Lead, Opportunity, Product2) and the custom objects you need.

Every custom build adds bugs to find and upkeep to carry. A short, scored list keeps the org clean.

Done when: every requirement is tagged standard, configurable or code, and the custom list has a business case for each item. If it slips: cut the code items and ship the standard ones first.

How do you migrate data into Salesforce?

Data migration is where bad data from the old system enters your new org. Clean it first, then load it in order.

1. Make an inventory of every source: spreadsheets, the old CRM, billing and support tools. Name an owner for each.
2. Write a mapping document. For each source column, list the Salesforce object and field it lands in, such as Opportunity.StageName or Contact.Email.
3. Add a custom text field called Legacy ID on each object, and mark it External ID. You can then upsert (update or insert) and keep relationships intact.
4. Clean the data before loading. Remove duplicates, fix formats and fill blanks. Plan duplicate prevention in Setup > Data > Duplicate Management, using matching rules and duplicate rules.
5. Choose the right tool. The Data Import Wizard (Setup > Data Management > Data Import Wizard) is for imports under 50,000 records on supported objects, per Salesforce Help. Data Loader is the desktop app from Salesforce. Use it for larger loads, unsupported objects, deletes and scheduled jobs. See Salesforce's Data Loader page and our Data Import Wizard vs Data Loader guide.
6. Load parents before children. Start with Users and Accounts. Then load Contacts and Opportunities. Load Products and price book entries last. A child record needs its parent to exist first.
7. Load one record first. Check it in Salesforce. Then load the rest. Salesforce's data migration best practices give the same advice.
8. Run at least two full test migrations in a sandbox. Have real end users check the second one.
9. Write a rollback plan before the real load. It should say how you find and delete loaded records if the load fails.

Done when: the second test migration passes a user check, with record counts and parent links matching the source. Undo: delete the loaded records by Legacy ID in the sandbox and reload. Never test-load into production.

How do you set up users, access and security?

Start with the least access that lets each person do the job. Then add more with permission sets.

1. Create users in Setup > Users > Users. Use one naming convention for usernames, and write it down.
2. Build the role hierarchy in Setup > Roles. Roles decide who can see whose records.
3. Set organization-wide defaults in Setup > Sharing Settings. Start private for sensitive objects such as Opportunity, then open access with sharing rules.
4. Keep profiles minimal. Give each profile only baseline access.
5. Grant extra access with permission sets (Setup > Permission Sets). Bundle the ones a job needs into a permission set group (Setup > Permission Set Groups). The permission set groups module shows how.
6. Set field-level security on sensitive fields, such as discount or salary fields.
7. Add validation rules (Setup > Object Manager > object > Validation Rules) so bad data cannot enter. For example, require a Close Date when Opportunity.StageName is Closed Won.
8. Document the security model in plain business terms, so auditors and trainers can follow it. The data security module covers each layer.

Done when: a test user with only a permission set group can do their daily tasks and cannot see restricted records. Undo: remove the permission set assignment (Setup > Permission Sets > Manage Assignments).

How do you configure the core Sales Cloud features?

Configure to match how reps work. Put the settings in a workbook as you go, with the reason for each choice.

1. Leads: set up routing in Setup > Lead Assignment Rules. Then decide when a Lead converts into an Account, a Contact and an Opportunity.
2. Opportunities: define the sales stages in Opportunity.StageName and set a probability for each one. Find the field in Setup > Object Manager > Opportunity.
3. Guided selling: add a Path (Setup > Path Settings) so each stage shows its key fields and tips.
4. Accounts: decide how parent and child accounts relate, using Account.ParentId.
5. Forecasts: turn on forecasting (Setup > Forecasts Settings) and match the forecast categories to your sales method.
6. Products: create Product2 records and a standard price book, then add price book entries.
7. Page layouts: remove fields nobody uses, and show the fields reps need at each stage.
8. Automation: build with Flow (Setup > Flows). Follow our Flow best practices so flows do not collide.
9. Integrations: pick one master system for each object. Set the sync frequency, the error handling and an alert for failed syncs. Start with the most important integration, usually marketing automation, and add others later.
10. Check the Salesforce mobile app, because many reps will use it.

Done when: each configured feature has a written reason in the workbook, and a sandbox test user can walk a Lead to a closed Opportunity. Undo: deploy only through change sets or DevOps Center, so each change can be reverted.

How do you test a Salesforce implementation?

Test in sandboxes, never in production. A sandbox is a copy of your org for building and testing. Salesforce offers four types. The figures below come from Salesforce Help on sandbox types.

Sandboxes are priced by Salesforce, and the cost depends on the type. See Salesforce sandbox pricing.

1. Build in a Developer or Developer Pro sandbox (Setup > Sandboxes > New Sandbox).
2. Write unit tests for every Apex class and trigger. Run them in Setup > Apex Test Execution.
3. Test every flow with sample records, and read the debug logs (Setup > Debug Logs) when a flow fails.
4. Test each integration end to end with real sample data.
5. Check each permission set by logging in as a test user (Setup > Users > Users > Login). Confirm the user can see and edit only what they should.
6. Run UAT in a Partial Copy sandbox. Recruit testers from every user group and give each one role-specific scripts.
7. Add "day in the life" tests where users do their normal work in the new system.
8. Log every defect, rank it, and fix the blockers before launch. Re-test after each fix.
9. Do a final dress rehearsal in a Full sandbox, with the full data volume.

Done when: all blocker defects are closed, every UAT tester has signed off, and the dress rehearsal load matches the source counts.

How do you train users so they adopt Salesforce?

One-size-fits-all training fails. Teach each role only what its job needs.

1. Build a training plan per role. The table below is an example you can adapt.
2. Mix live sessions, short videos, quick reference guides and in-app guidance (Setup > In-App Guidance).
3. Point admins and power users to the Admin Beginner trail.
4. Ask users to show their skills in a short exercise before they get full access, rather than only attend a session.
5. Pick adoption measures now: logins, records created, data completeness and process adherence.

Done when: each role has finished its training and passed a short practical exercise.

How do you go live without surprises?

Go-live is a short, planned event. Write a runbook with owners, times and clear go or no-go criteria.

1. Freeze changes in the old system and set a cutover time, ideally outside working hours.
2. Take a backup of the source data and of your target org's metadata.
3. Run the final load in dependency order. Check record counts and parent-child links against the source.
4. Deploy the final changes to production. Use an outbound change set from the sandbox to production (Setup > Outbound Change Sets), described in Salesforce Help on change sets. If your team uses version control, use DevOps Center, which tracks changes as work items and moves them through a pipeline. Our change sets vs DevOps guide compares the two.
5. Run a smoke test: create a lead, convert it, close an opportunity, and open the key reports and dashboards.
6. Check that every integration is connected and every scheduled flow is active.
7. Send the go-live notice with quick reference guides, and name where people get help.
8. Hold a daily check-in for the first week. Triage issues the same day.
9. Celebrate early wins in public to build momentum.

Clientell AI asks before it changes anything in production, and it reads your org in read-only mode first. Read how we handle your data on the privacy and security page.

How do you keep improving after launch?

The project ends, but the work does not. Set up a rhythm for review.

1. Review adoption and data quality monthly, using Salesforce reports and dashboards.
2. Collect user feedback and rank requests by business impact.
3. Ship enhancements in planned releases through your sandbox path.
4. Check results against the goals from phase 1, and write down what you learned.
5. Run the Setup Audit Trail (Setup > View Setup Audit Trail) to see who changed what.
6. Set a governance process: a change request form, a release calendar and development standards.

A clear governance model keeps the org clean after the project team leaves. Our free health check gives you a read-only baseline to compare against each quarter.

Need hands-on help? See our Salesforce services.

Sources

Salesforce documentation

• Salesforce Sales Cloud pricing
• Sandbox types and storage limits
• Data Import Wizard limits
• Data migration best practices
• Deploy change sets from sandbox to production
• DevOps Center overview
• Permission set groups module
• Data security module
• Admin Beginner trail

Last reviewed October 2026

Last updated: October 22, 2026