Most Salesforce projects that struggle do so for reasons that were visible before the first configuration change. Working through the points below early saves weeks of rework later.
1. Agree on the business outcomes
Start with what should be different after go-live: faster quote turnaround, a reliable forecast, fewer support escalations. Each outcome should have an owner and a way to measure it. Features are then chosen because they move one of these numbers, not because they are available.
2. Map how work happens today
Walk through the real process with the people who do it — how a lead becomes an opportunity, how a case is routed, who approves a discount. Document the exceptions as well as the happy path. Exceptions are where most custom configuration ends up.
3. Decide what data comes across
Migration is usually underestimated. Before moving anything, decide:
- which objects and how many years of history you actually need
- who owns cleaning duplicates and incomplete records
- how records will be matched between the old system and Salesforce
Clean data at go-live is one of the strongest predictors of user trust in the new system.
4. Keep the first release small
A focused first release that teams use every day beats a large one that arrives late. Plan a roadmap of smaller releases, and use feedback from each one to shape the next.
5. Plan adoption, not just training
Training sessions alone rarely change habits. Identify champions in each team, build dashboards that managers rely on in their reviews, and retire the old spreadsheets on a fixed date.
Planning a Salesforce rollout? Talk to our team about where to start.