Salesforce to Salesforce Retirement: What Actually Replaces It

Salesforce to Salesforce has been free since Salesforce first shipped it in December 2007: no separate licence, no extra product, just a checkbox in Setup and a sharing rule connecting two orgs. Nineteen years later, Salesforce has confirmed the retirement: by the Spring '27 release, the feature stops working entirely - and none of the three replacements Salesforce names in its own retirement notice are free.

The short answer

In brief: Salesforce to Salesforce (S2S) - the native feature for sharing records like leads, opportunities, and custom objects between two separate Salesforce orgs - is being retired via an official Release Update, in three phases running from Spring '26 through Spring '27. Most orgs never touched it and have nothing to do. The ones that should act now are the minority actually using it in production: distributors and franchise networks sharing deal data with a parent org, companies running two orgs after an acquisition, or any partner data exchange set up years ago that nobody's revisited since. We covered a different wave of Salesforce integration-layer retirements - OAuth password logins, SOAP's login() call, hardcoded instance URLs - in the integration deadlines landing in 2027; this is a separate, fifth deadline worth tracking on its own, because unlike those four, it retires a whole feature rather than an authentication method, and the replacement isn't a settings change - it's a genuine architecture decision.

What the Salesforce to Salesforce retirement actually changes

Salesforce to Salesforce lets two separate Salesforce orgs connect directly and share selected object records in near real time - a lead created in one org can appear in a partner's org automatically, an opportunity update can sync back, without either side building or maintaining an API integration. It's been the quiet, zero-cost way plenty of manufacturers, distributors, and multi-org enterprises have kept partner or subsidiary data in sync since 2007. Salesforce has now published a Release Update - its formal mechanism for retiring platform functionality on a fixed schedule - confirming S2S is going away for good, not being quietly deprecated while it keeps limping along indefinitely.

1. Spring '26

   New Salesforce to Salesforce connections blocked

   Existing connections keep working; an org that hasn't already enabled S2S can no longer turn it on for the first time.

2. Summer '26

   Official support ends

   Salesforce stops providing support for S2S issues. Every remaining connection is now running unsupported.

3. Spring '27

   Full retirement - the feature stops working

   Every remaining Salesforce to Salesforce connection is switched off with this release, regardless of how long it's been running or how business-critical it is.

Who should actually care - and who shouldn't

This matters if your org has an active Salesforce to Salesforce connection doing real work: sharing deal registration or account data with channel partners who run their own Salesforce org, keeping two orgs in sync after an acquisition brought a second Salesforce instance into the company, or passing records between a parent company and a franchise or dealer network. If any of that sounds familiar and you're not certain it still runs through S2S specifically rather than a newer integration, that uncertainty is worth resolving on its own - it's exactly the kind of dependency a Salesforce Health Check is built to surface alongside the rest of an org's integration inventory.

This doesn't matter if your org never enabled S2S, or if whatever partner data sharing you do already runs through Experience Cloud, a modern middleware integration, or an AppExchange connector - true for most orgs built or refreshed in the last several years. It's also not the same deadline as the OAuth and SOAP retirements covered in our integration-deadlines piece: an org can be completely clear of those and still have an S2S connection running quietly in the background, because it's configured as a data-sharing feature, not an authentication method, and it typically doesn't show up in the Connected Apps or Login History reports admins already check for the other deadlines.

Choosing what replaces it

Salesforce names three replacement paths in its retirement notice - Partner Cloud, Data Cloud One, and MuleSoft (Anypoint or MuleSoft for Flow) - and lists them almost interchangeably. They aren't. Each solves a different version of the underlying problem, and picking the wrong one means paying for a platform that doesn't match why you were using S2S in the first place. This is closer to an architecture decision than a Setup migration, and it's worth getting an outside view on before committing to a licence - a Salesforce Health & Roadmap engagement or a similar architecture review is the right scope for it, not a rushed change made against the deadline.

What to do now

1. Search Setup for Salesforce to Salesforce Connections and confirm whether your org has any active connections - not everyone who set one up years ago remembers it's still running.
2. For each active connection, identify what it actually does: which objects sync, in which direction, and who on the other end depends on it. This is the step most likely to turn up a connection nobody currently owns.
3. Classify each connection against the table above - partner-facing, internal multi-org, or simple point-to-point - before evaluating any specific product.
4. If Partner Cloud or Data Cloud One licensing is already in place for other reasons, check whether the S2S replacement can ride on that investment rather than starting a separate procurement conversation.
5. Build in real lead time for whichever replacement you pick. A portal-based Partner Cloud rollout or a Data Cloud One data model isn't a same-week migration, and Spring '27 is closer than the release-train naming makes it feel.

What not to do yet

• Don't buy MuleSoft Anypoint or Partner Cloud licensing before confirming what your existing S2S connections actually sync. It's common for a years-old connection to carry far less live traffic than assumed, and a narrower replacement might be all that's needed.
• Don't assume Partner Cloud is a drop-in technical replacement for S2S. It's a different product built around a partner portal and community model, not a record-sync mechanism - migrating to it changes how partners interact with your data, not just how it moves.
• Don't wait for Salesforce to force the issue. Support already ended in Summer '26; treating this as a live-until-Spring-'27 problem ignores that any issue with an existing connection between now and then is yours to solve without Salesforce's help.

Why none of the replacements are free - and why that matters more than the migration

It's worth naming the part of this that isn't really about technology. Salesforce to Salesforce cost nothing to turn on - it shipped in every org, no separate SKU. Partner Cloud, Data Cloud One, and MuleSoft are all separately licensed products with their own pricing conversations. For an organisation that's been quietly relying on a free integration mechanism for the better part of two decades, this retirement isn't just an engineering migration - it's a new recurring cost that needs a budget owner and a business case, not just a Setup change. Naming that early, to whoever owns the Salesforce budget, is worth doing before the technical migration plan, not after.

A few questions worth asking before Spring '27

Does Salesforce to Salesforce still work right now?

Yes, for orgs that already had it enabled - existing connections keep running through the Summer '26 support cutoff and up to the Spring '27 release, when they stop working entirely. What changed as of Spring '26 is that no org can turn S2S on for the first time; anything already running continues on borrowed time rather than being switched off immediately.

Is this the same deadline as the OAuth and SOAP retirements?

No - they're unrelated, timed separately, and worth tracking as two different items rather than one. The OAuth username-password flow, SOAP's login() call, and the other items in our integration deadlines piece are about how an integration authenticates to Salesforce's APIs. Salesforce to Salesforce is a specific feature for sharing records between two orgs, and its retirement removes the feature itself, not just one way of logging into it. An org can be completely unaffected by one and still need to act on the other.

Can we just rebuild the same thing ourselves instead of buying a replacement product?

For a narrow, well-understood connection, yes - a custom point-to-point integration built on standard REST APIs through existing middleware can replicate what a simple S2S connection was doing, without adopting Partner Cloud or Data Cloud One. That's a reasonable option specifically for the "simple record sync, no portal, no shared data model" row in the table above. It stops being reasonable the moment the connection is doing anything closer to partner collaboration, where a purpose-built product genuinely does more than a custom sync job would.

The bottom line

Salesforce to Salesforce isn't a widely used feature in 2026, which is exactly why this retirement is easy to miss - it doesn't show up in the same audits as the OAuth and API deadlines everyone's already tracking. If your org has never touched it, there's nothing to do. If it has, the deadline is real, the replacement isn't a checkbox, and none of the three paths Salesforce names cost what the feature you're replacing did. Confirm which of your orgs still has an active connection first, and treat the choice between Partner Cloud, Data Cloud One, and MuleSoft as the architecture decision it actually is - we're happy to help you scope it if the audit turns up more than a quiet, unused checkbox.