How to rescue a failed Salesforce implementation

Most failed Salesforce implementations can be rescued without starting over. The first step is a short assessment that separates what works from what does not; the second is stabilizing whatever the business depends on today; the third is a keep, fix or rebuild decision for each part of the build. A full restart is only justified when the data model itself does not fit how the business works.

Why do Salesforce implementations fail?

Salesforce implementations usually fail for business reasons, not technical ones. The common causes are unclear requirements, no single decision-maker on the client side, too much scope in the first release, poor data brought across unchanged, and too little training or ownership after go-live. The platform can do what most companies need; projects fail when nobody decides what that is.

• Requirements that describe screens and fields instead of the process and the decisions it supports.
• Several stakeholders with a veto and nobody with the final say, so decisions stall or reverse.
• A first release that tries to deliver every team, cloud and integration at once.
• Legacy data migrated as it was, so duplicates and gaps undermine trust from day one.
• Heavy customization where standard configuration would have worked, which makes every later change slower.
• Launch treated as the finish line, with no admin, roadmap or adoption plan behind it.

Signs a project needs rescuing

• The go-live date has slipped more than once, with no firm new date.
• The system is live but teams have gone back to spreadsheets or the old tool.
• The previous partner or admin has moved on and nobody understands the build.
• You are paying for licenses or features nobody can use.
• Every change breaks something else.

The first two weeks

• Get admin access and a copy of the original scope, designs and any documentation.
• Interview the people who were supposed to use the system: what they need, what they avoid, what breaks.
• Inventory the org: objects, automation, custom code, integrations, managed packages and licenses.
• List what the business depends on right now, and stabilize that first.
• Compare what was promised with what was built, and note the gaps.

Keep, fix or rebuild

What rescues look like in practice

An industrial-services firm had paid a previous partner more than $100,000 for a Salesforce Field Service build it could not use. Within a 20-hour engagement, the scheduling errors were fixed and a custom Labor Resource object removed the need for Field Service licenses for 75–100 field workers. A medical-device company regained a broken Pardot instance by removing 970+ invalid records and restoring its automation. A political-advocacy agency moved a failed two-year Tableau investment to a working roadmap and active progress.

What evidence should you collect in the first week of a rescue?

Gather facts from the org and the paperwork before forming opinions. You want a record of what exists, what was paid for and what changed recently.

• The Setup Audit Trail, which shows recent configuration changes and who made them.
• Failed Flow interview emails, Apex exception emails and integration error logs.
• Login History by role, which shows which teams have stopped using the system.
• Every signed statement of work, change order and invoice, so paid scope can be compared with delivered scope.
• Test scripts and sign-offs, if any exist, and the requirements they actually covered.
• The workarounds users rely on, such as side spreadsheets, with the reason behind each one.

Hold back on fixes during this week unless the business is at risk. Unrecorded changes make it harder to separate old faults from new ones.

How do you handle the previous partner and the contract?

Keep every exchange factual, written and focused on what you need next. A cooperative handover is usually worth more than winning an argument.

• Ask your legal counsel how to pause or end work under the current contract before announcing anything.
• Send one written request listing the access, documentation and open work you need, with a date.
• Record gaps between the statement of work and the delivered build, with evidence, before discussing money.
• Keep any fee dispute on a separate track, so knowledge transfer is not held hostage to negotiation.
• Do not let the incoming and outgoing teams trade blame in front of your users.

How should you present a rescue plan to executives?

Start with what the business depends on and when it will be stable, then show the options and their costs. Leaders who were let down once want fewer promises and more checkpoints.

• One page stating what works, what is broken and what the business is losing today.
• The keep, fix, rebuild and retire result for each area, with the reason for each call.
• A small first release that fixes the most painful problem before any new features.
• Named owners on both sides, including the client decision-maker the first attempt lacked.
• Checkpoints where leadership sees working software and decides whether to continue.
• The risks that remain, stated plainly rather than buried in an appendix.

Who should own the rescue on your side?

Name one senior person who can settle process questions and say no to new scope. That owner needs protected time, because a rescue produces a steady flow of decisions.

• Choose someone who uses the outputs of the system, such as a sales or service leader, not only IT.
• Give them authority to retire features, even ones the first project delivered at great effort.
• Pair them with the person who will administer the org once the rescue ends.
• Have them approve the success measures at the start, so progress is judged against something agreed.