The biggest Salesforce implementation challenges are rarely technical. Projects usually go wrong because goals are vague, the scope keeps growing, data is moved without being cleaned, the system is over-customised, and the people who must use it are brought in too late. Each of these mistakes shows early warning signs, and each can be prevented, or fixed, if you know what to look for.
This post was first published in 2020 as "7 common Salesforce implementation mistakes". It has been rewritten for 2026 for business leaders who are planning, running or rescuing a Salesforce project.
What makes Salesforce implementations hard?
Salesforce is quick to switch on and very flexible, which is both its strength and its risk: almost anything can be built, so the hard part is deciding what should be. Salesforce's own CRM implementation guide names data migration issues, resistance to adoption, inadequate training, scope creep and poor planning as common challenges, and says overcoming them takes clear communication, strong leadership and ongoing support. For the phases and roles of a well-run project, see our companion guide, 7 keys to a successful Salesforce implementation. This post focuses on what goes wrong.
The 10 most common Salesforce implementation mistakes
The ten mistakes below account for most troubled projects; the first four are decisions made before any configuration starts.
- No measurable goal. "Implement Salesforce" is not a goal; "cut quote turnaround from three days to one" is. Without it, every request seems equally important.
- Copying old processes as they are. Rebuilding a spreadsheet or legacy system screen by screen carries its workarounds into the new platform.
- Scope creep. New requirements keep arriving during the build, and the first release slips because it tries to do everything.
- No business owner. IT runs the project, but nobody in sales or service has the authority to make decisions or the time to test.
- Poor data quality and late migration. Duplicates, blanks and outdated records are moved as they are, often in the final week.
- Over-customisation. Custom code and automation are built where standard features would do, making every later change slower and more expensive.
- Integrations planned last. ERP, billing or marketing connections are treated as an add-on, then turn out to drive the whole data model.
- Testing squeezed at the end. User acceptance testing becomes a demo, and problems surface after go-live.
- Training on features, not jobs. Users learn where the buttons are but not how to do their daily work in the new system.
- Treating go-live as the finish line. Nobody owns the system afterwards, feedback goes nowhere, and adoption slowly falls.
Early warning signs and how to prevent each mistake
Every one of these mistakes is visible weeks before go-live if you know the sign to look for.
| Challenge | Early warning sign | Prevention |
|---|---|---|
| Unclear goals | Different leaders describe different reasons for the project | Agree three to five measurable outcomes before design starts |
| Copied processes | Requirements read like the old system's screens | Map how the work should happen, with a business analyst, before mapping fields |
| Scope creep | The backlog grows every week and the release date moves | Fix a minimum first release; park everything else for phase two |
| No business owner | Decisions wait for meetings; testers are "too busy" | Name a product owner with time allocated and authority to decide |
| Data quality | Nobody can say how many duplicate accounts exist | Profile, clean and trial-load data early; see our data migration strategies |
| Over-customisation | Custom code is proposed before standard features are reviewed | Configuration first; justify each custom build against an outcome (see configuration vs customisation) |
| Late integrations | "We'll connect the ERP later" | Design integrations with the data model; see our integration patterns guide |
| Thin testing | No test scripts; UAT is one session | Test in a proper sandbox with real scenarios and real users |
| Weak training | Users first see the system on training day | Role-based training built around daily tasks, plus a pilot group |
| No post-launch owner | No budget or team after go-live | Plan an admin or support model before launch |
Data: the challenge that sinks the most projects
Data deserves its own section because it affects everything users see on day one. If the first account a sales rep opens is a duplicate with missing contacts, trust in the system is lost. Trailhead's data quality unit suggests assessing data on six dimensions before you fix anything:
- Age: how recently records were updated.
- Completeness: whether the fields each business use needs are filled in.
- Accuracy: whether values are correct.
- Consistency: whether dates, currencies, countries and regions follow one format.
- Duplication: how many records describe the same customer.
- Usage: whether the data is actually used in reports, dashboards and apps.
Start the data workstream at the same time as design, not after the build. Moving less, cleaner data is almost always better than moving everything.
Are AI agents a new implementation challenge?
Yes. Adding Agentforce or other AI agents makes data quality and testing even more important, because an agent acts on whatever data it can see. Salesforce's CRM implementation guide lists training AI agents correctly and keeping data unified among the extra challenges AI brings, and advises piloting agents with a small group of users before a wider rollout. Treat an agent like any other release: a clear goal, clean source data, a sandbox test and a pilot.
Phased rollout and choosing a partner
A phased rollout lowers risk: launch a minimum first release to one team or region, learn from it, then extend. Salesforce's guide puts planning (timeline, scope, resources and success metrics) before any customisation, and ends with evaluation and iteration rather than go-live. If you use an implementation partner, ask to see how they handle discovery, data migration, testing and handover, and who will be on your project day to day, not only at the sales stage.
User adoption: the challenge after go-live
A system people don't use has failed, however well it is built. Salesforce's guide notes that proper training minimises resistance to change and boosts adoption. After launch, Trailhead's adoption strategies unit recommends gathering feedback from users, sharing success stories, and benchmarking performance before Salesforce and tracking how it changes afterwards. It also reminds teams that Salesforce releases new features three times a year, so someone should review each release for features that help.
Useful measures to track from the first month include weekly active users by team, the share of opportunities or cases updated in Salesforce rather than elsewhere, data completeness on key fields, and the business outcome you agreed at the start, such as quote turnaround or case resolution time. Our reports guide shows how to build these dashboards.
How to rescue a struggling Salesforce implementation
- Pause new features. Stop adding to a system people are not using until you understand why.
- Get an independent review. Look at the org's configuration and code, data quality, and how users actually work, including what they do outside Salesforce.
- Agree a short list of outcomes. Pick the two or three results the business most needs, such as reliable pipeline reporting.
- Fix the blockers to those outcomes first. Often that means cleaning data, simplifying page layouts and removing unused fields and automation.
- Retrain by role and appoint champions in each team.
- Put ongoing ownership in place, in-house or through managed services, so the system keeps improving.
A full rebuild is rarely needed. If the problem is several overlapping orgs, see our org consolidation service.
Questions to ask before you start
Six questions, answered in writing before design begins, prevent most of the mistakes above.
- What three measurable outcomes will tell us the project worked?
- Who on the business side owns decisions, and how much of their time is allocated?
- What is in the first release, and what is explicitly not?
- When will data be profiled, cleaned and trial-loaded?
- Which systems must integrate, and who owns each one?
- Who will support and improve Salesforce after go-live?
Budget matters too; our Salesforce implementation cost guide explains what drives the price.
Getting help
Techila is a Salesforce Summit Partner. Our Salesforce implementation services team plans new implementations to avoid these mistakes and reviews and rescues projects that are struggling. Talk to us about your project.
Frequently asked questions
What are the most common Salesforce implementation challenges?
Unclear business goals, scope creep, poor data quality and migration problems, over-customisation, weak integration planning, too little testing, inadequate training and low user adoption. Salesforce's own CRM implementation guide lists data migration, adoption resistance, inadequate training and scope creep among the common ones.
Why do Salesforce implementations fail?
Most fail for business reasons rather than technical ones: nobody agreed what success looks like, the scope kept growing, data was moved without cleaning, and users were not involved or trained. The system goes live, but people keep working in spreadsheets.
How can I tell if my Salesforce project is in trouble?
Warning signs include requirements that keep changing late in the build, no named business owner, testing squeezed into the last week, data migration left until just before go-live, and users who have not seen the system before training day.
Can a failed Salesforce implementation be rescued?
Usually, yes. Start with an independent review of the org, the data and how people actually use it, then agree a short list of business outcomes, fix the blockers to those first, and simplify customisation that nobody uses. A full rebuild is rarely needed.
How do I avoid over-customising Salesforce?
Start from standard features and configuration, and write custom code only when a documented requirement can't be met otherwise. Ask for every custom build to be justified against a business outcome, and review automation and fields regularly to remove what is unused.