If your Salesforce implementation isn’t working properly, do not scrap it entirely or add further customizations. First, stabilize it: halt changes, back up your metadata and data, and secure admin access. Then, honestly assess adoption, data quality, architecture, and governance. Most failing implementations are recoverable; the platform is rarely the real problem. What follows is what actually to do next.
Key takeaways
- Stabilize before you diagnose. Freeze changes, back up, secure access. Resist the urge to build your way out.
- Assess honestly across goals, adoption, data, architecture, security, and governance, and keep the diagnosis separate from any sales pitch.
- Most failures are structural, not technical. Ownership, process, and adoption sink more projects than the platform ever does.
- Pick the right path: optimize, redesign, or restart, and never relaunch under the governance that failed you.
- Tell leadership early, with options. Plus, a recommendation keeps their confidence.
Table of Contents
First, don’t panic, but do stop digging.
The instinct when a project is going sideways is to do something. Add a field. Build another automation. Bring in a new consultant who promises to fix everything in two weeks. Resist that. When you’re in a hole, the first job is to stop digging.
For the first 48 to 72 hours, your goal is stabilization, not transformation. Practically, that means a few concrete things. Put a change freeze on the org so no one is making it worse while you figure out what’s wrong. Back up your metadata and your data with a proper export, not a vague assumption that it’s “in there somewhere.” Confirm who actually has System Administrator access and trim the list to people who should. And start a simple running log of every known risk, issue, and open question, because you will not remember them all and you’ll need them for the harder conversations coming.
If the org is live and actively disrupting people’s daily work, stabilizing operations comes before optimizing anything. A broken lead-routing flow that’s dropping inbound deals is a “fix today” problem. The elegant data model refactor can wait.
How bad is it, really? Run an honest health check
You can’t plan a recovery until you know what you’re recovering from, and this is the step people most want to skip. It’s uncomfortable to look directly at the mess. Do it anyway.
A real assessment covers more ground than most people expect:
- Goals and Vision: Was there ever a written, measurable definition of success? “We need a CRM” is not a goal. If nobody can tell you what winning looked like, that’s a finding in itself.
- Adoption: Are people actually using it? Salesforce’s own Trailhead module on user adoption metrics points you at login activity, data quality, and feature usage as the signals that matter, and the free Salesforce Adoption Dashboards on AppExchange give you a fast read on logins and feature uptake.
- Data Quality: Duplicates, empty required fields, migrated records nobody trusts. Bad data quietly kills adoption because the first time a rep sees garbage, they stop believing the system.
- Architecture and Technical debt:Â Stacked automations on the same object, a sprawl of custom objects where a handful would do, undocumented integrations. An organization rarely collapses overnight because of this; rather, the issues accumulate gradually, making every future change unnecessarily difficult.
- Security: Run the native Health Check under Setup → Security → Health Check. It scores your org against a baseline and flags high-risk settings. Worth knowing: this tool is specifically about security configuration, not overall project health; don’t confuse a green security score with a healthy implementation.
If you are looking for an external framework to underpin all of this, Salesforce’s ‘Well-Architected‘ guidance serves as an excellent benchmark. It evaluates whether your solution is reliable, simple, and adaptable; secure for your stakeholders; capable of delivering value quickly; and able to evolve. Assess your organization against these three criteria, and any shortcomings will naturally come to light.
Why Salesforce Implementations Actually Fail
Here’s the thing almost nobody in a panic wants to hear, and it’s also the good news. When implementations underperform, the causes are usually structural, not technical.
In my experience, the failures cluster into five buckets:
- Scope and Requirements: No one documented what success meant, so the build chased a moving target. Or the opposite: endless customization that turned a configurable platform into a fragile custom app.
- Data: Migration was treated as a technical copy-and-paste job rather than a business exercise. No field mapping, no reconciliation, no rollback plan. The data lands, nobody trusts it, and that’s that.
- Adoption: This is the big one. If reps don’t use it, nothing else you built matters. Adoption is a change-management problem, and it’s where the gap between “we went live” and “it actually works” shows up most brutally.
- Technical debt: Over-customization and unmanaged automation that slow everything down and make enhancements weirdly expensive.
Governance:Â No single owner, no intake process, no executive who cares. Here’s a litmus test I’ve relied on for years: if you can’t name the person who actually owns Salesforce in a few minutes flat, the project is already quietly in trouble.
Notice that four of those five are about people and process. That’s why “the platform is rarely the problem” isn’t a platitude.
About that “70% of implementations fail” stat
You’ve probably seen the claim that 70% of CRM projects fail. Be careful repeating it. The claim originated from a 2001 Gartner survey that measured projects that “failed to meet expectations,” a very different thing from “failed.” In a 2004 CustomerThink interview, Gartner analyst Ed Thompson said people “chopped the ‘meet expectations’ off it and just said, ‘failure,'” and noted the outright-failure figure was only around 5%. Treat the scary number as folklore. For what it’s worth, Boston Consulting Group’s 2020 research on digital transformation found roughly 70% of those efforts fall short of their targets, real and sourced, but about transformation broadly, not Salesforce specifically.
The Big decision: triage, rescue, or restart
Once you know what’s wrong, you have three honest options, and picking the right one matters more than how hard you work afterward.
| Situation | What it means | Typical path |
|---|---|---|
| Users want to use it, but it's buggy or slow | Technical issues on a sound foundation | Optimize — highest odds of success |
| Users bypass the workflow because it doesn't fit how they work | Process and design flaws | Redesign the affected processes |
| The architecture fundamentally doesn't match the business | Wrong foundation | Restart the affected pieces |
A full system rebuild is not as common as people think; most “failed” projects can be salvaged through the right kind of intervention. Here is a rough rule of thumb: if you have spent more than 60% of the budget but less than 30% of the planned functions are operational, salvaging the project might cost more than starting over. This is just an estimate, not a hard-and-fast rule; use your judgment.
However, one thing is certain: do not restart the project under the same management or system that caused it to fail in the first place. If a leaderless committee sank it the first time, handing the responsibility of restarting it to that same committee guarantees the same outcome. Address the root cause before rebuilding; otherwise, you will recreate the same problem.
How to tell leadership the truth without losing their confidence
This is the kind of conversation people dread, and handling it well often saves not just the project, but one’s career as well.
Deliver the news; don’t sit on it hoping things improve. The worst version of this is the executive who learns the project is in trouble from someone other than you. When you do brief them, lead with the facts, then your read on what they mean, then a recommendation. Come with options and a preferred path, not just a bag of problems dumped on the table.
Keep it concise and candid. Most executives want the headline first, not a slow build-up. Admit what you don’t know yet and say when you’ll know it. And don’t sugarcoat; leaders can smell a minimized problem, and it costs you more trust than the bad news itself ever would. Alison Sigmon’s SED approach Separate the facts from your reaction, Evaluate the real impact, then Deliver is a decent structure if you want one.
Building the Recovery Roadmap
Once the decision has been made and the cooperation of all concerned parties secured, the reconstruction work proceeds in a largely reliable manner.
Rescope hard to a minimum viable set of outcomes. Not everything on the original wishlist; the handful of things that deliver real business value. Then ship one genuine, working win fast. A deployed feature people can actually use rebuilds confidence faster than any status deck.
Rebuild governance before you re-implement. That means a real owner, an executive sponsor who stays engaged, and a simple intake-to-release loop the bones of a Center of Excellence, even a small one. On the people side, pair the technical work with change management. The Prosci ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement, from Jeff Hiatt’s 2006 book) is the standard framework practitioners lean on, and its logic is useful for diagnosis too: adoption stalls at the first missing element, so find which one is missing.
Plan for intensive care following the relaunch: provide robust support to individuals during the adjustment period and continuously evaluate the process rather than simply assuming success. Quarterly reviews, conducted within a structured framework, will help identify issues before they escalate.
Preventing the next failure — and getting AI-ready
There is a crucial point to consider: Salesforce is heavily focused on ‘Agentforce‘ and has recently rebranded ‘Data Cloud‘ to ‘Data 360’. This means the quality of your existing data has become even more critical. Fragmented metadata, outdated automation, and incomplete documentation not only slow down your team but also quietly undermine the performance of AI and agents within your organization. Therefore, the cleanup and improvements you undertake to salvage this project are the very same steps that prepare you for AI. If you needed one more reason to do it properly, there it is.
Final Thoughts
Before making any changes, complete a 48-hour stabilization checklist: freeze operations, back up data, secure access, and start logging issues. Once the situation stabilizes, set aside two hours to evaluate your org based on the ‘Salesforce Well-Architected’ pillars of Trusted, Easy, and Adaptable. This scoring session typically clarifies whether you should optimize, redesign, or restart, transforming vague anxiety into an actionable plan.
Frequently Asked Questions (FAQ)
Most things can be fixed. Starting completely from scratch is the exception, not the rule. Start over only when the existing architecture is fundamentally unsuited to the business needs, or when the cost of fixing it is roughly equal to the cost of rebuilding it from scratch.
Low user adoption, which is usually a symptom of weak change management and unclear ownership rather than a technical flaw. If people don’t trust the data or the process, they revert to old habits.
Watch for low login rates, reps working outside the system, data nobody trusts, and no clear answer to “who owns Salesforce here?” Any two of those together is a real warning sign.
Not automatically. Do a root-cause assessment first. Sometimes the problem was scope, sponsorship, or internal ownership rather than the partner’s work, and switching partners without fixing that repeats the failure.
Do it early and directly. Start by presenting the facts, explaining their implications, and suggesting a way forward; do not simply list the problems. Do not underestimate the leaders’ capacity to handle the situation; speak with candor rather than relying on mere hope.
No. It scores your security configuration, which matters, but it says nothing about adoption, data quality, or architecture. Use it as one input in a broader assessment.
Akanksha Shukla
Akanksha is a Content Writer at SalesforceTrail.com, contributing educational content that supports Salesforce professionals in learning, growing, and advancing their careers within the Trailblazer ecosystem.
- Akanksha Shukla
- Akanksha Shukla
- Akanksha Shukla
- Akanksha Shukla
