Switching Salesforce Partners Mid-Project: How to Do It Without Losing Six Months

Most companies don't decide to switch Salesforce partners the day something visibly breaks. They decide the day someone asks a routine question - why the account hierarchy is built this way, what a particular Flow actually does, why an integration keeps silently retrying - and the answer that comes back doesn't match what's live in the org. If that answer is a guess, or a request for more billable hours to go find out, that's the real signal. The missed deadline or blown budget everyone remembers later is usually just the moment leadership finally noticed.

The instinct once that happens is to treat it as a binary: keep the partner, or rebuild from zero with someone new. Neither is usually right. A Fix Sprint-style bounded engagement to stabilise what exists, or a controlled handover to a new partner, both cost a fraction of a from-scratch rebuild - the six months of budget and disruption a full restart usually costs is rarely a bill the org actually needed to pay. This guide is written for the point before you've committed to anything permanent: what actually distinguishes a real partner problem from normal project friction, what to secure before you say anything to the incumbent, and how to run the transition itself so a new partner isn't reconstructing your org from memory.

The short answer

In brief: treat a partner problem as three separate decisions, not one. First, confirm it's genuinely a partner failure and not ordinary project friction - a Salesforce Health & Roadmap review is the fastest honest way to find out if you can't tell from the inside. Second, decide whether the right response is repairing the relationship, running a bounded engagement to stabilise what's there, or switching partners or bringing the work in-house entirely - a decision that depends on scale and trust, not frustration alone. Third, if you are switching, secure access and documentation before you say anything to the incumbent, then run the handover as a phased transition, not a hard cutover. Get the order right and a partner change is disruptive for weeks, not months; get it backwards - telling the partner first, discovering what you don't actually have access to second - and it can cost most of a year.

Is this actually a partner problem?

Not every rough patch is a partner failure, and treating normal project friction as a firing offence usually just produces a second failed relationship with a different name on the contract. The distinction worth making before anything else:

• A basic question about the org gets a guess, not an answer - what a Flow does, why a field exists, which system owns a piece of data. A partner who built or maintains something should be able to explain it without a discovery re-run.
• Every clarification becomes a change order. Some scope growth is normal; a pattern of billing extra hours to explain existing work, not build new work, is different.
• The same defect reopens across releases without the underlying cause ever being named, only patched again.
• Nobody on the account can say who's actually doing the work. A team that was senior at the sales stage and junior at delivery is a staffing problem wearing a technical one's clothes.
• Documentation, where it exists at all, doesn't match what's actually deployed - a mismatch that's usually the first thing an incoming partner or reviewer finds.
• Responsiveness dropped off after the contract was signed, particularly around anything that isn't new, billable work.

None of these individually is disqualifying - a genuinely good partner can have a slow month. What matters is whether it's a pattern across more than one of these, and whether it's been raised and simply not fixed. A single missed deadline on a complex integration is normal delivery risk; a partner who can't explain their own prior work when asked plainly is a different category of problem.

Fix the relationship, stabilise, switch, or bring it in-house

Once it's clearly a partner problem, the next decision isn't yet 'who's the new partner' - it's which of four responses actually fits the situation.

That last row is a genuinely different question from the other three, and worth not collapsing into it just because both start with the same bad experience - see managed services vs. an in-house team for where that threshold actually sits.

Secure this before you say anything to the incumbent

If the decision is a full switch, sequence matters more than most companies expect. Telling an underperforming partner they're being replaced before confirming what you actually have access to is the single most common way a transition turns expensive, because the moment that conversation happens, cooperation on anything beyond the contract's letter tends to drop sharply, whatever the partner's actual intentions. Confirm the following first, quietly, while the relationship is still active:

1. Who legally owns the Salesforce org, sandboxes, and any connected middleware accounts - confirm it's the company, not a login tied to the partner's own credentials.
2. Full admin access for someone on your side, not just the partner's team - a login you control, tested and working, not one that's supposed to work.
3. A current export of metadata, custom code, and configuration - a change-set or version-control history if one exists, a full metadata retrieve if it doesn't.
4. Every connected app, API key, and integration credential, and confirmation of which were created by the partner versus the company's own accounts.
5. The contract's IP and deliverables clauses - what you're explicitly entitled to keep, and whether custom code was work-for-hire or licensed.
6. A written list of open defects, in-flight work, and anything time-sensitive - a scheduled release, a pending integration cutover - that can't simply pause.

None of this requires confrontation. Routine access reviews and documentation requests are normal governance, not an accusation, and framing them that way keeps the relationship intact long enough to actually collect what you need.

How a clean handover actually moves

Once access and documentation are secured, resist the instinct to cut over in a single weekend. A phased handover - in the spirit of Salesforce's own project-management guidance for taking over an existing project - keeps production stable while institutional knowledge actually transfers, instead of just changing hands on paper.

What a new partner should be able to tell you in week one

The same due-diligence gap that let the last partner underperform is easy to repeat with the next one, particularly under pressure to just get someone in place. A new partner worth signing should be able to, inside the first one to two weeks:

• Name specifically who will do the day-to-day work, not just who ran the sales conversation - the gap between a strong pitch team and a strong delivery team is the most common blind spot in partner selection.
• Point to comparable delivery experience for your specific scope, not a generic client logo wall.
• Push back on at least one thing you've asked for, with a reason - a partner who agrees with every request in week one is optimising for the sale, not the outcome.
• Give a credible, specific estimate for how long a full audit of the inherited org will take, rather than promising an instant fix.
• Discuss what happens after go-live, not just during it - ongoing support terms and cost, not only the build.

This is also where a genuinely honest partner will sometimes say the org doesn't need full replacement - that a bounded engagement covers it, or that the real gap is documentation and access rather than technical quality. That answer costs them a larger contract, which is exactly why it's usually the more trustworthy one. Our own senior architects start most engagements this way: auditing what's actually there before proposing what to do about it, which is also why Salesforce Health & Roadmap exists as a structured version of that same first step rather than something done only informally.

Mistakes that turn a transition into a second failure

A few mistakes account for most transitions that go worse than the partner problem they were meant to fix:

• Terminating access before exporting anything. Once a login is deactivated, recovering metadata and configuration depends entirely on the departing partner's cooperation - exactly the cooperation a bad breakup tends to end.
• Treating a rebuild as the default. Most inherited orgs have more usable structure than a frustrated leadership team assumes; a full rebuild is occasionally the right call, but it should be a conclusion from the audit, not a starting assumption.
• Skipping a written transition scope with the new partner. 'Just take it over' produces the same undocumented-ownership problem a year later, with a different vendor's name on it.
• Relying on a verbal handover call instead of a written inventory. Institutional knowledge that only exists in a meeting nobody recorded is exactly as fragile as the single-admin risk that shows up when one person leaves.

Questions worth asking before you sign or send anything

Can we take our Salesforce metadata and custom code with us?

Usually yes, but confirm it against your specific contract rather than assuming it. Salesforce metadata and configuration live in an org you own regardless of who built it; ownership of custom code and documentation depends on the contract's IP and work-for-hire terms, which is exactly why reviewing that clause is one of the access-and-asset steps above, not an afterthought once the relationship has already ended.

How long does a clean partner handover actually take?

There's no honest universal number, and it's worth being skeptical of anyone who quotes one without first asking how much custom automation, how many integrations, and how much - or how little - documentation you're handing over. What's consistent across transitions that go well is that the phased sequence above is measured in weeks when a reasonable inventory exists, and closer to months when almost nothing was documented. The gap between those two isn't the new partner's competence; it's whether the previous one, or anyone internally, ever wrote anything down.

Should we bring the work in-house instead of hiring another partner?

Sometimes, and it's worth answering honestly rather than defaulting to 'never again' right after a bad experience. That's a separate decision from fixing the immediate problem - see managed services vs. an in-house team for the thresholds that actually distinguish the two - and a partner change gone badly is a poor moment to make it under pressure. Stabilise first, decide the sourcing model deliberately second.

The bottom line

A Salesforce partner that isn't working out is a solvable problem, not a sunk one - but only if the order of operations is right. Confirm it's genuinely a partner failure rather than normal friction, secure access and documentation while the relationship is still intact, decide deliberately between repairing it, stabilising it, or switching fully, and run any handover as a phased transition rather than a single cutover weekend. Do that, and a partner change costs weeks of disruption. Skip the sequence, and the same change can cost most of a year for reasons that had nothing to do with Salesforce itself. If you're not sure yet which category your situation falls into, talk to an architect before you say anything to your current partner - or start with a Salesforce Health & Roadmap for an honest, independent read on what's actually there.