If two of your Salesforce orgs, or your org and a partner’s, still exchange records through Salesforce to Salesforce (S2S), you have a deadline. Salesforce says the feature will be fully retired in all orgs with the Spring ’27 release and will stop working. The retirement applies to the legacy S2S feature, not to integration or data migration between Salesforce orgs in general. The Salesforce to Salesforce retirement is easy to put off because nothing is broken today. This guide covers what has already changed, how to find everything that depends on S2S, and how to choose and test a replacement.
What Salesforce has announced
Salesforce’s retirement notice describes S2S as a legacy feature for sharing records between orgs and supporting vendor and partner co-selling. It sets out three stages:
- Spring ’26: admins can no longer enable S2S in an org. Orgs that already had it enabled keep it working.
- Summer ’26: support ended. S2S gets no bug fixes or enhancements, although customers can still log support cases.
- Spring ’27: S2S is fully retired in all orgs and stops functioning.
Salesforce’s Winter ’27 architect highlights repeat the Spring ’27 retirement, and Salesforce’s Active Product & Feature Retirements list gives the timing as Spring ’27, February 2027. Treat that as a release window rather than a single shutdown date. The retirement arrives as each instance is upgraded to Spring ’27, so check the dates for each of yours, sandboxes included, and plan to the earliest.
Why it is easy to underestimate
S2S connections tend to be old. A typical one was set up years ago for a reseller, then extended to a second object, then copied for a subsidiary. The admin who configured it may have left, and nobody wrote down which reports or processes now depend on records arriving from the other org.
When such a connection stops, you may see no error at all. Records simply stop arriving, and someone notices weeks later, after the two orgs have drifted apart.
Find every connection and what depends on it
Start with an inventory, one row per connection. For each, record:
- Who is on the other side: an external partner or reseller, a subsidiary, another business unit, or an org you have since merged.
- What moves: which objects and fields, in which direction, and roughly how many records a month.
- How sharing starts: users forwarding records by hand, or Apex or other automation sharing them automatically. Search your code and automation for S2S references, because automated sharing is the part people forget.
- What consumes it: reports, dashboards, assignment rules, flows and integrations that rely on the shared records.
- Who owns it: a named business owner who can say whether it is still needed.
We use the same inventory-first method for authentication retirements, described in debugging the SOAP login() retirement.
Match each connection to a replacement
Salesforce’s notice does not name a single successor. It points to four options, each for a different need:
- Partner Cloud for sharing data and collaborating with resellers or partners through a branded experience with visibility and controls.
- Data Cloud One for companies with several orgs that need unified customer data, identity resolution and cross-org reporting.
- MuleSoft Anypoint for complex, bespoke integrations across many systems, including legacy or on-premises applications.
- MuleSoft for Flow for integrations built in Flow Builder, including communication between two Salesforce orgs.
Salesforce notes that these alternatives carry licence or cost impacts, so price the shortlist with your account executive. Co-selling with an external partner is a different problem from two internal orgs sharing customers, so let the inventory drive each choice.
Two other outcomes are often right. Some connections can simply be switched off because the partnership behind them has ended. Others exist only because the business runs two orgs that should be one, and consolidation removes the need to share at all; our account of merging five regional orgs into one shows what that involves.
Run old and new side by side, carefully
Salesforce says you can run S2S alongside a replacement, but that you may see duplicate data in one or more orgs. It recommends validating the new approach in a sandbox without S2S configured. Plan the parallel run deliberately:
- Agree a matching key before the run starts, so the new route updates records that S2S created rather than inserting second copies.
- Move one connection at a time, each with its own cutover date and owner.
- Reconcile record counts and a sample of field values in both orgs before you stop sharing through S2S.
- Keep a fallback until the new route has run cleanly through a full business cycle.
Our guide to planning a zero-downtime org cutover covers rehearsal, reconciliation and rollback.
How we help
Our data migration team starts with the inventory, then helps you choose a replacement for each connection, plan the parallel run and reconcile the two orgs before S2S switches off. For partner-facing sharing, the answer is usually one of the Salesforce options above, and we will say so.
Where the right move is to consolidate orgs or bring data from one org into another, our own product, iSyncSF, moves data between Salesforce orgs. iSyncSF is not one of the alternatives listed in Salesforce’s retirement notice. It runs natively inside Salesforce and keeps lookups and parent-child relationships intact. We validate every move in a sandbox before it touches production.
Frequently asked questions
Can we still enable Salesforce to Salesforce in a new org?
No. Salesforce says admins have not been able to enable S2S since the Spring ’26 release. Only orgs that already had it enabled can keep using it until Spring ’27.
Will Salesforce fix S2S problems before it is retired?
Salesforce says support ended with the Summer ’26 release: no bug fixes or enhancements, although you can still log a support case.
Is there a like-for-like replacement for S2S?
Not a single one. Salesforce recommends Partner Cloud, Data Cloud One, MuleSoft Anypoint or MuleSoft for Flow depending on the use case, so each connection needs its own decision.
Key takeaways
- Salesforce says S2S stops working in all orgs with Spring ’27, so start now.
- Inventory every connection, including automated sharing, and name an owner for each one.
- Choose a replacement per connection, test it in a sandbox without S2S and manage duplicates during the parallel run.