Change Salesforce consulting partners without losing access, context, or delivery momentum using a controlled inventory, transition, and recovery process.
Key takeaways
- Secure access and delivery assets before the transition.
- Stabilize production before starting new features.
- Validate source and documentation against the live org.
- Give the replacement team a bounded first objective.
Switching Salesforce consulting partners should be managed as a controlled transition, not a sudden restart. The immediate goal is to protect access, preserve context, stabilize production, and establish a trustworthy view of what exists. New feature work comes after that foundation.
You do not need a complete diagnosis before deciding that a relationship no longer works. You do need a transition owner inside the business who can collect assets, make access decisions, coordinate vendors, and approve the first recovery priorities.
When should you switch Salesforce consulting partners?
Switch when the delivery relationship no longer provides a credible path to a supportable outcome. One missed date or disagreement may be recoverable. A pattern of unclear ownership, repeated surprises, missing evidence, and declining trust deserves a structured review.
Signals that warrant action include:
- Milestones move repeatedly without an updated scope or risk explanation.
- Production behavior differs from demos and no one owns the defect path.
- Important decisions live in meetings or private messages instead of shared records.
- Source, deployment history, test evidence, or documentation cannot be produced.
- The delivery team changes frequently and context is repeatedly lost.
- Change requests appear because original assumptions were never made explicit.
- Security, data, integration errors, or user access concerns remain unresolved.
- The team cannot explain what is complete, what is safe, and what remains open.
Before terminating the relationship, separate commercial frustration from platform risk. If the project can be reset with named owners, a revised scope, and objective acceptance criteria, that may be faster than a full transition. If trust or control cannot be restored, prepare the switch.
What should you collect before changing Salesforce partners?
Collect the information and access required to operate the platform without depending on one firm. Store it in company-controlled systems with appropriate access.
Build an inventory covering:
Commercial records
- Statements of work, amendments, change orders, invoices, warranties, and support terms.
- Open decisions, accepted deliverables, disputed items, and remaining commitments.
- Contracts with package vendors, integration providers, and related consultants.
Salesforce access and environments
- Production, sandbox, and development environment ownership.
- Named user access, permission assignments, connected apps, certificates, and integration identities.
- Release tools, deployment pipelines, repositories, and package ownership.
- Salesforce support cases and relevant vendor support threads.
Do not copy passwords or tokens into a general transition document. Confirm who owns each credential, rotate it through the proper secret-management process when appropriate, and avoid breaking an active integration before its dependency is understood.
Technical assets
- Current source, metadata, custom code, flows, packages, and deployment records.
- Data model, field mappings, external IDs, duplicate rules, and migration files.
- Integration diagrams, endpoints, authentication methods, mappings, error handling, and operating owners.
- Security model, external access, sharing decisions, and known exceptions.
- Test plans, user acceptance results, defects, and rollback instructions.
Business context
- Process maps, requirements, acceptance criteria, training materials, and decision logs.
- Backlog with priority, owner, status, dependency, and business reason.
- Named product owner, Salesforce admin, subject-matter experts, and approvers.
An inventory is not proof that the assets match production. The incoming team must validate them against the live org.
How do you transition to a new Salesforce partner?
Use a short sequence with explicit gates.
1. Stabilize
Pause nonessential change while the team identifies production incidents, security concerns, failed integrations, blocked users, and time-sensitive commitments. Define who can approve an emergency release during the transition.
2. Secure control
Confirm company ownership of environments, repositories, deployment services, documentation, vendor accounts, and administrative access. Keep required services running while access dependencies are mapped. Then remove or reduce former-partner access deliberately, using named users and least privilege.
3. Validate the current state
Compare available source and documentation with production. Inventory active automation, custom code, integrations, packages, access patterns, data jobs, and open defects. Mark each item as verified, uncertain, or missing.
4. Triage the backlog
Separate production risk, contractual completion, operational pain, and future enhancements. Do not carry every old request into the new plan unchanged. Reconfirm the business reason and owner.
5. Choose a bounded first release
Give the incoming team one objective that can prove its delivery model. It might stabilize an integration, close a security gap, complete one blocked workflow, or produce an approved recovery roadmap. Define acceptance before work begins.
6. Reopen delivery gradually
Resume planned work after access, source, testing, and release ownership are reliable. Preserve a decision log and require each release to leave the org easier to operate.
Should the old and new Salesforce partners overlap?
A short overlap can help when the outgoing team has unique system knowledge and the relationship remains professional. The overlap should have a written agenda and named artifacts, not open-ended knowledge-transfer meetings.
Use the time to answer:
- Which components are active, deprecated, experimental, or incomplete?
- Which releases are in progress, and where are they represented in source?
- Which integrations fail silently or require manual intervention?
- Which credentials, certificates, jobs, or vendor accounts have renewal dates?
- Which design decisions were deliberate, even if they now look unusual?
- Which defects and data corrections remain open?
- What does the internal team need to operate tomorrow?
If overlap is not possible, do not accept assumptions as facts. The incoming partner should inspect the org, deployment assets, logs, data, and user behavior before proposing a rebuild.
What should a replacement Salesforce partner do first?
The replacement partner should establish evidence before recommending major change. A credible first phase produces a current-state inventory, risk list, ownership map, prioritized recovery plan, and estimate basis.
Be cautious if the immediate answer is to rebuild everything. Some existing work may be sound, some may need repair, and some may be obsolete. The decision should follow inspection.
LOVALTO's Implementation Recovery is designed for stalled or compromised delivery. When the condition is unclear but the project is not actively failing, a Health Check can provide a prioritized independent view.
Use the Salesforce partner selection guide for the replacement search. Ask candidates how they validate production, preserve usable work, control access, and create a first release that earns trust.
How do you prevent the same problem with the next partner?
Keep ownership inside the business and make delivery evidence part of the engagement from the start.
Require:
- A named internal product owner and platform owner.
- A named delivery lead and clear responsibility map.
- Shared source, backlog, decisions, tests, and deployment records.
- Acceptance criteria tied to business behavior and realistic user access.
- Visible assumptions, exclusions, risks, and change control.
- Documentation and knowledge transfer throughout delivery.
- A defined support and warranty path after go-live.
The goal is not to make switching easy because partners are disposable. It is to make the platform operable because your company retains control of its decisions, assets, and knowledge.