Why do Salesforce implementations fail?
Salesforce implementations usually fail for a handful of reasons: requirements that were never agreed, a design built around the tool instead of the process, poor data migration, too much custom code, no owner on the client side and too little training. Most failed projects can be recovered without starting over once those causes are identified.
Signs you need an implementation rescue
- Your go-live date has slipped more than once.
- The system is live but teams have gone back to spreadsheets.
- Your previous partner has moved on and nobody understands the build.
- You are paying for licenses or features nobody can use.
What we deliver (5)
Recovery assessment
A review of the build, data and original scope to separate what works from what does not.
Stabilization
Urgent fixes so the business can operate while the plan is agreed.
Keep, fix or rebuild
A clear decision for each component, avoiding a full restart where possible.
Completion
Delivery of the remaining scope with documentation your team can maintain.
Re-launch
Training and adoption support so users give the system a second chance.
Implementation Rescue, phase by phase (4)
What happens in each phase, what you get at the end of it, and what we need from your team.
- 01
Assess
We start by getting read access to production and every sandbox, then pull the metadata, the original statement of work, change orders and any design notes. The sponsor and a handful of daily users are interviewed separately, because their accounts of what went wrong rarely match. Each promised requirement is traced to what was actually built, the data is sampled for quality, and every integration, managed package and scheduled job touching the org is listed.
- 02
Stabilize
Before anyone debates the long-term plan, we stop the bleeding. Typical fixes: flows and triggers that block record saves, sharing that hides accounts from the reps who own them, integrations writing bad data that need pausing, and the reports leadership reviews every week. Each fix moves through a sandbox and a written change log, so the org is not destabilized a second time by well-meant patches made straight in production.
- 03
Decide
Every object, flow, Apex class, page layout and integration gets a verdict: keep as built, fix in place, rebuild or retire. We weigh each one against the process it is meant to support, what depends on it and how hard it will be to maintain. Custom code that duplicates standard functionality is a frequent retire candidate. The output is a recovery plan with a sequenced backlog, an owner for each decision and a realistic re-launch target.
- 04
Finish
The backlog is delivered in small, demonstrable increments so users watch the system improve instead of waiting for one big reveal. Data is corrected or re-migrated wherever the first load went wrong. Components are documented in plain language alongside an admin runbook. Before re-launch, the people who abandoned the system run acceptance tests, training is delivered by job role, and we stay close through the first weeks of renewed use.
What drives the effort in a rescue (6)
| Factor | Keeps effort down | Raises effort |
|---|---|---|
| Access to the original build | Admin logins, the prior statement of work and some design notes are all in hand. | Nobody holds a working admin login and the previous partner left no documentation or handover. |
| Volume of custom code | The build leans on declarative tools such as flows, standard objects and page layouts. | Large amounts of Apex, triggers and custom components with thin or missing test coverage. |
| Condition of migrated data | The first data load was mostly accurate and needs only targeted cleanup. | Records arrived with broken relationships, duplicates or missing history that must be loaded again. |
| Integration footprint | Salesforce mostly stands alone or connects to one well-documented system. | Several middleware jobs push data into the org and nobody can explain what each one does. |
| Clarity of original goals | Leadership can still state what the project was supposed to achieve and who owns it. | Requirements were never agreed, and departments now disagree about what success should look like. |
| Remaining user trust | Users are frustrated but still logging in and reporting problems as they find them. | Teams have fully retreated to spreadsheets or another CRM and must be won back. |
Rates typically range from $185 to $225 per hour depending on scope and expertise required, and you get a written estimate after discovery, so these factors are what we ask about first.
Related client work (4)
Common implementation rescue mistakes (4)
- 01
Ending the contract before securing access
When a relationship sours, companies often terminate first and ask for a handover later. By then the outgoing partner may hold the only admin credentials, the integration user, the code repository and the deployment pipeline. Secure a system administrator login, control of connected app credentials and copies of code and documentation before notice is given, not after.
- 02
Treating a rebuild as the default
Starting fresh feels clean, but it discards work that was paid for and frequently functions. It also burns through whatever patience users have left and pushes value further out. Most recovered orgs keep a meaningful share of the original configuration. Judge each component on its merits; a rebuild should be where the evidence leads, not the assumption you begin with.
- 03
Patching directly in production
Under pressure, internal admins and newly hired vendors fix problems straight in the live org. Each untested change adds another variable, and some quietly break automation somewhere else. Recovery work needs a sandbox, a change log and a simple release routine from the first day, even when the fixes are small and the business is impatient for them.
- 04
Re-launching without winning users back
People who were burned once will not return because an email announces the system is fixed. They need to see their own complaints resolved, get trained on the version they will actually use and hear from their managers that Salesforce is the system of record again. Skip that step and a technically sound org still sits empty.
Questions to ask before you sign (5)
A recovery partner inherits someone else's decisions, and the wrong firm can repeat them. Look for one that diagnoses before it quotes, is comfortable finishing work it did not start, and can explain its reasoning to people who are already skeptical of Salesforce consultants. These questions help find that partner.
- 1
How will you assess our org before proposing a plan?
Listen for a defined assessment that reviews metadata, data and the original scope, and that interviews both leaders and everyday users. A partner who recommends a rebuild after one demo call is guessing. Strong answers spell out what they need from you and what the assessment can and cannot tell you.
- 2
What will you keep from the current build, and how do you decide?
A credible partner has criteria: fit with the real process, maintainability, dependencies and test coverage. They should expect to keep some of the existing work. Be wary of anyone who shows no interest in your configuration, since that usually signals a preference for building their own way instead of recovering yours.
- 3
Have you taken over projects from another partner before?
Ask for examples in your clouds and your industry. Good answers describe handover mechanics such as securing credentials, reading undocumented code and untangling a half-finished deployment. We have been a Salesforce Consulting Partner since 2017, and much of our recovery work begins in an org another firm built.
- 4
How will the business keep running while you fix things?
Recovery cannot pause sales or service. Look for a stabilization step aimed at the issues costing the most each day, fixes released through a sandbox, and interim workarounds for users. A partner who wants to freeze the org until a full rebuild is ready is asking you to absorb the cost.
- 5
How will you hand the system back to our team?
The failed project probably left you dependent on a single outside party. A good answer covers plain-language documentation, an admin runbook, recorded training and a period where your admin works alongside theirs. You should finish able to maintain the org yourself or switch providers without needing another rescue.
Products, industries and markets
Salesforce products we work with here
Implementation Rescue by industry
Industries where we have delivered implementation rescue
Markets where implementation rescue is a common need
Guides on salesforce implementation rescue (3)
Salesforce Implementation Rescue questions (9)
Can you take over a Salesforce project from another partner?
Yes. An industrial-services firm had paid a previous partner over $100,000 for a Field Service build it could not use. Within a 20-hour engagement we fixed the multi-day scheduling errors and eliminated per-worker licensing for 75–100 laborers.
Do we have to start over?
Rarely. Most failed implementations have usable parts. The assessment decides what to keep, what to fix and what to rebuild.
How quickly can you start?
We begin with a short assessment so we understand the build before promising a plan. Stabilization fixes can often start while the full recovery plan is being agreed.
Do you rescue Marketing Cloud and Tableau projects too?
Yes. We recovered a broken Account Engagement (Pardot) instance for a medical-device company, removing 970+ invalid records, and salvaged a failed two-year Tableau investment for an advocacy agency.
What should we get from our previous partner before they leave?
At minimum: a system administrator login, credentials for every integration user and connected app, the code repository if one exists, the statement of work and change orders, design documents and a list of open defects. Also ask about any deployment tooling they set up and who owns the licenses for installed packages. If the relationship has already ended, we can still work from the org itself, but recovering this material first removes a lot of guesswork.
Can a live org with active users be rescued, or does it need to go offline?
A live org can almost always be recovered in place. We work in sandboxes, release fixes on a planned schedule and tell users about changes before they arrive. A few steps, such as reloading data or reworking the sharing model, may need a brief scheduled window, but those are planned with your team so sales, service and operations keep moving throughout the recovery.
Our teams abandoned Salesforce after launch. Can they be won back?
Fix the problems they complained about most and tell them specifically what changed. Simplify page layouts and remove fields nobody fills in. Train by role on the real system rather than a demo, and have managers run meetings from Salesforce reports. One manufacturer's reps had stopped using its org entirely; after we consolidated record types, cut redundant automation and captured email automatically, all 99 reps were active.
Is a rescue different from a health check?
A health check is diagnostic: it measures an org against good practice and gives you a prioritized list of findings. A rescue includes that kind of review but goes further, stabilizing the system, making keep, fix or rebuild calls and delivering the remaining scope. If you cannot tell whether your project is failing or just rough around the edges, a health check is a sensible place to start.
Who owns the recovered org and its documentation when you finish?
You do. Everything we build lives in your Salesforce org and your repositories, under accounts your company controls. Documentation, runbooks and training recordings are handed over as part of completion, written for your admins rather than for us. Ongoing support afterward is a separate choice. Nothing in the recovery depends on keeping us engaged, and a new provider could pick up the work from the same materials.