The Salesforce platform is mature, stable and used by organisations of every size. Yet many teams can describe a rollout that went live late, cost more than planned and still left users working in spreadsheets. When that happens, the software is almost never the root cause.

This article explains why Salesforce projects fail, the warning signs that one is in trouble, and a practical five-phase playbook for rescuing it. It is based on the patterns we see when organisations ask us to take over or stabilise an implementation.

Nine warning signs your Salesforce project is in trouble

1. The go-live date has moved more than once without a clear, agreed reason.
2. Nobody can state the business outcome the project must deliver in one sentence.
3. User acceptance testing keeps producing new requirements rather than defects.
4. Data migration is "nearly ready" weeks before launch, and no trial load has been reconciled.
5. Every change request becomes custom code, even for standard processes.
6. Integrations are tested only with happy-path data.
7. Business users are not attending demos or send juniors with no decision rights.
8. Budget reports show hours spent but not features accepted.
9. After go-live, logins fall and teams rebuild their old spreadsheets.

Two or three of these signs justify a review. Five or more means the project needs intervention now.

Why do Salesforce projects fail? The root causes

1. Unclear objectives and success measures

"Implement Sales Cloud" is not an objective. "Give leadership a reliable weekly forecast and cut quote turnaround from three days to one" is. Without measurable outcomes, every stakeholder’s wish list looks equally important.

2. Weak executive sponsorship

Salesforce changes how people work. When decisions about process, ownership and priorities have no senior sponsor, they are deferred, and deferred decisions become delays and rework.

3. Recreating the old system

Teams often ask for their legacy screens and workarounds to be rebuilt exactly. The result is heavy customisation, higher cost and a platform that is harder to upgrade, while the old problems move into the new system.

4. Over-customisation

Custom code has its place, but using Apex and custom components where standard features or Flow would work creates long-term maintenance cost. Our article on custom Salesforce solutions discusses where customisation genuinely pays off.

5. Data migration treated as an afterthought

If users log in on day one and cannot find their accounts, or see duplicates, they stop trusting the system immediately. Data work needs its own plan, owners and trial loads. Our CRM migration playbook shows what good looks like.

6. Big-bang launches

Launching every team, process and integration on one date concentrates risk. A phased rollout gives you earlier feedback and smaller failures.

7. Partner or team mismatch

A team that is excellent at configuration may lack integration or data expertise, and vice versa. Frequent staff rotation on the partner side also erodes knowledge. Knowing how to choose the right Salesforce consultant prevents many of these problems.

8. Adoption and training ignored

Training a week before launch, with generic slides, does not change behaviour. Role-based training, champions in each team and managers who run meetings from Salesforce dashboards do.

9. No governance after go-live

Without a clear owner, backlog and release process, the org collects unmanaged changes quickly, and the problems that caused the original trouble return.

The five-phase Salesforce project rescue playbook

Phase 1: Stabilise (weeks 1–2)

• Pause new feature development that is not critical to go-live or business continuity.
• Fix production-blocking defects and failing integrations first.
• Confirm who makes decisions, and set a short weekly steering meeting with the executive sponsor.
• Communicate honestly with users about what is being fixed and when.

Phase 2: Assess (weeks 2–4)

Run a structured review of the org and the project. Our 30-point Salesforce org health check covers the technical side. Add a project assessment:

• Which original objectives are still valid, and which features actually support them?
• What has been built, what is accepted, and what is partially complete?
• Where is the data: migrated, clean, reconciled?
• Which integrations are reliable and which are fragile?
• What do users say, team by team?

Phase 3: Reset scope and plan (weeks 4–5)

• Re-state business outcomes and measures of success.
• Split the backlog into must-have for the next release, next phase and not now.
• Decide, component by component, whether to keep, simplify or rebuild.
• Agree a realistic plan with smaller releases and clear acceptance criteria.

Phase 4: Deliver visible quick wins (months 2–3)

Momentum restores confidence. Choose improvements users will notice quickly, such as a cleaner opportunity page, a trustworthy pipeline dashboard, removing duplicate data entry or fixing a slow process. Release them in short cycles and show the results at the steering meeting.

Phase 5: Govern for the long term

• Appoint a platform owner and a small design authority for significant changes.
• Introduce source control, sandboxes and a predictable release process. See Salesforce DevOps and test automation.
• Track adoption measures monthly against the business outcomes.
• Schedule an annual org health check.

Our guide to Salesforce best practices and governance expands on this phase.

Repair or rebuild? A decision guide

Question	If yes	If no
Does the data model fundamentally not fit how the business works?	Lean towards rebuild of affected areas	Repair
Would fixing custom code cost more than replacing it with standard features?	Replace those components	Refactor in place
Is the security model so tangled that access cannot be verified?	Redesign security with a clean permission set model	Tidy incrementally
Are most integrations unreliable or undocumented?	Re-platform integrations with a clear pattern	Harden the weak ones
Do users actively use at least part of the system?	Protect what works and repair around it	Consider a fresh start for that team

Questions to ask a Salesforce rescue partner

• How will you assess the org before recommending changes, and what will the output look like?
• Which parts of our current build do you expect to keep, and why?
• How will you keep the business running while you fix things?
• Who will be on the team, and how will you retain knowledge if people change?
• How will you measure success, beyond "go-live"?
• Can you share an example of a similar rescue, even anonymised?

What should the executive sponsor do during a rescue?

• Restate the outcome the organisation needs, and protect the team from new scope until it is delivered.
• Make decisions within days, not weeks, especially on standardising processes between teams.
• Show up at demos and steering meetings, and run their own reviews from Salesforce dashboards.
• Hold business leaders accountable for data quality and user adoption in their teams, not only the delivery team.

A rescue scorecard for steering meetings

Review a short scorecard every week during the rescue. It keeps the conversation on outcomes rather than activity, and it makes deteriorating trends visible before they become crises.

Measure	Healthy signal	Warning signal
Production defects	Falling week on week, no critical defects open	Critical defects open for more than a few days
Accepted backlog items	A steady flow of items accepted by the business	Items stuck in testing or repeatedly reopened
Decisions outstanding	Few, each with an owner and a date	A growing list with no owners
Data quality	Duplicate and incomplete record counts trending down	New duplicates still being created
Adoption	Active users and records updated rising in every team	Teams still working in spreadsheets
Integration health	Failures detected by monitoring and resolved within a day	Failures discovered by users
Budget	Spend tracks accepted scope	Spend grows while accepted scope does not

How to prevent failure on your next Salesforce initiative

• Write measurable objectives and get the sponsor to sign them.
• Fund discovery properly before fixing the budget for the build. Our implementation cost guide explains why this lowers total cost.
• Adopt standard processes wherever the business can.
• Treat data migration and training as workstreams with owners and deadlines.
• Release in phases, and measure adoption after each one.

Need help getting a Salesforce project back on track?

Groviya has stabilised and completed Salesforce implementations started by other teams, working from India, the UK and the USA. We start with an honest assessment, protect what works, and focus on the outcomes your business originally set out to achieve. Explore our Salesforce services or talk to a rescue specialist.