On this page (5)
It is time to switch Salesforce partners when problems repeat after you have raised them clearly: missed commitments, work nobody can explain, rotating consultants or an org that gets harder to change. To switch safely, confirm your own admin access, collect documentation and credentials, review your contract’s notice and handover terms, and overlap the outgoing and incoming partners where you can. The new partner should start by assessing the org, not by picking up the backlog as if nothing changed.
Signs it is time to change partners
Every partnership has rough patches. The signals that matter are patterns that persist after an honest conversation:
- Deadlines slip repeatedly and the explanations change each time.
- You are on your third or fourth lead consultant and keep re-explaining your business.
- Nobody can tell you why a piece of automation or code exists.
- Simple requests take weeks, while invoices arrive on schedule.
- Releases break things users rely on, and testing seems to happen in production.
- Your needs have outgrown the partner, for example a new cloud, an ERP integration or AI work they do not do.
- You no longer trust the status reports.
If only one or two of these apply, try raising them formally first, in writing, with specific examples and a request for a plan. Some relationships recover once expectations are reset. If the same issues return, switching is usually less disruptive than continuing.
Before you give notice
The riskiest moment in a partner change is the gap between announcing it and the new team being ready. Most of that risk disappears if you prepare quietly first.
- Confirm at least one employee holds System Administrator access, with multi-factor authentication, and does not depend on the partner to log in.
- Find out which integrations, scheduled jobs and connected apps run under a partner consultant’s user, and plan to move them to a dedicated integration user you control.
- Read your contract for notice periods, transition assistance, ownership of work product and any fees for early termination. Ask your own legal counsel if the terms are unclear.
- Check who holds credentials for middleware, AgentExchange (formerly AppExchange) packages, sandboxes and any source control repository.
- Agree how work in progress will be handled, so half-finished changes are either completed, documented or rolled back before the handover.
If your internal administrator has also left, our checklist for when a Salesforce admin leaves covers the access and user-ownership steps in more detail.
Handover checklist
Ask the outgoing partner for the following, ideally in a single handover package with a walkthrough meeting. You are entitled to understand the system you paid for, even if some items need to be reconstructed later.
| Item | What good looks like | Why it matters |
|---|---|---|
| Admin access and credentials | All logins, API keys and middleware accounts under your ownership | Prevents a lockout or broken integration on the day the contract ends |
| Solution documentation | Data model, security and sharing design, and the reasons behind key decisions | The new team can change things safely instead of guessing |
| Automation and code inventory | Every Flow, trigger, Apex class and scheduled job, with its purpose | Hidden automation is the most common cause of breakage after a handover |
| Integration details | Endpoints, schedules, error handling and who to contact at each vendor | Integrations fail quietly when nobody knows how they work |
| Source code and deployment history | A repository or change log showing what was deployed and when | Lets the new partner see recent changes and roll them back if needed |
| Open work and known issues | The backlog, work in progress and workarounds users rely on | Stops work from being lost or done twice |
| Project records | Statements of work, requirements, test scripts and sign-offs | Shows what was promised against what was delivered |
Running the transition
Where the contract allows, overlap the two partners for a short period so the incoming team can ask questions while the people who built the org are still available. Keep that overlap focused on knowledge transfer rather than new features.
The incoming partner’s first piece of work should be an assessment: a health check of the org, a review of the handover material against what is actually built, and a list of risks ranked by business impact. Only after that should the backlog restart, with the most urgent fixes first. Pausing new feature requests for a short time is normal and saves rework.
Tell your users what is changing and who to contact. A partner switch is invisible to most of them until something breaks, and a clear support route avoids requests getting lost between two firms.
A switch can recover real value. An industrial-services firm came to us after a previous partner delivered a Field Service system it could not use; within a 20-hour engagement, the multi-day scheduling errors were fixed and a custom Labor Resource object removed per-worker licensing for 75-100 laborers.
What to ask the new partner
- How do you take over an org another firm built, and what do you review first?
- What will you need from the outgoing partner, and what can you reconstruct if they do not provide it?
- How will you decide what to keep, fix or rebuild?
- Who will be our day-to-day contact, and how do you keep knowledge from sitting with one person?
- How will you document changes so that we are not in the same position again?
- Can you cover ongoing administration and development, or only project work?
If the handover is going badly, or the org is in worse shape than expected, a rescue approach is more appropriate than a routine takeover. Our guide to rescuing a failed Salesforce implementation covers the keep, fix or rebuild decision in depth.
Questions people also ask
Is it risky to switch Salesforce partners mid-project?
Switching partners mid-project carries risk, but most of it can be managed with preparation. The riskiest moment is the gap between announcing the change and the new team being ready. Before you give notice, make sure an employee holds System Administrator access, move integrations off partner users, read your contract's notice and handover terms, and agree how work in progress will be completed, documented or rolled back.
Can a new partner take over a failing Salesforce project?
Yes. The incoming partner's first piece of work should be an assessment: a health check of the org, a review of the handover material against what is actually built, and a list of risks ranked by business impact. Only then should the backlog restart, most urgent fixes first. If the org is in worse shape than expected, a rescue approach fits better than a routine takeover.
When should we switch Salesforce partners?
Switch when problems repeat after you have raised them clearly, such as missed commitments, work nobody can explain, rotating consultants or an org that gets harder to change. If only one or two signs apply, raise them formally first, in writing, with specific examples and a request for a plan. If the same issues return, switching is usually less disruptive than continuing.
How long does it take to switch Salesforce partners?
It depends on a few things you can check before you give notice: the notice period and transition terms in your contract, whether your own staff already hold admin access and integrations run on users you control, how complete the outgoing partner's handover package is, and how much work in progress must be finished, documented or rolled back. Allow time for a short overlap and for the new partner's assessment before the backlog restarts.
