Salesforce to Salesforce Stops Working in Spring '27: Find Your Connections and Choose What Replaces Them

TL;DR

• Salesforce to Salesforce (S2S) is fully retired with Spring '27 and stops functioning in every org. It goes on your instance's Spring '27 upgrade weekend, not on one fixed date.
• It has been winding down in phases. Since Spring '26 nobody can switch it on. Since Summer '26 it gets no bug fixes or enhancements, though you can still log support cases.
• One query tells you whether it matters to you. If PartnerNetworkConnection does not exist in your org, S2S was never enabled and you can stop here.
• If it does exist, list the connections and the records they share, then find any Apex, automation or integration that depends on them.
• Salesforce suggests a replacement by use case: Partner Cloud for partners who resell your products, Data Cloud One for sharing data across your own orgs, and MuleSoft Anypoint or MuleSoft for Flow for everything else.
• Salesforce says all of the alternatives have "some license or cost impact". Budget conversations take longer than the technical work, so start them first.

What You'll Learn

• The retirement timeline, and how to find the date it reaches your org
• How to tell in one query whether your org uses S2S at all
• How to list your connections, what they share, and what depends on them
• How to match each connection to the replacement Salesforce suggests
• What to check that is easy to miss: code, integrations, reports and the cross-org adapter

The Problem

Salesforce to Salesforce is an old feature, and that is part of the risk. It lets two orgs share records: one org publishes objects, the other subscribes, and records forwarded across a connection are created and kept in step in the other org. Companies set it up years ago to pass leads to resellers, to share opportunities with a partner they co-sell with, or to keep two of their own orgs in step after an acquisition.

Because it was set up years ago, the people who configured it have often moved on. It runs in Salesforce Classic, on a Connections tab most admins never open. Records arrive in the receiving org looking like any other record, so the business process that depends on them does not obviously depend on S2S at all. The first sign that it has stopped may be a partner asking why the leads dried up.

Salesforce has been retiring it in phases, and the last phase removes it. With Spring '27, S2S is fully retired in all orgs and no longer functions. There is no migration tool. Replacing it means choosing a different product for each thing it does, and those products have licence costs.

Common questions this article answers:

• When does Salesforce to Salesforce stop working in my org?
• How do I check whether my org uses Salesforce to Salesforce?
• What replaces Salesforce to Salesforce?
• Will my Apex or integrations break when S2S is retired?

Quick Answer

Salesforce to Salesforce is fully retired with the Spring '27 release and stops working on your instance's Spring '27 upgrade weekend. To check whether you use it, run this query:

sf data query --target-org my-org --query "SELECT Id, ConnectionName, ConnectionStatus, ConnectionType, ResponseDate FROM PartnerNetworkConnection"

If it fails with "sObject type 'PartnerNetworkConnection' is not supported", S2S was never enabled in that org and the retirement does not affect it. If it returns rows, each row is a connection. For each connection that is still accepted and still sharing records, decide what replaces it. Salesforce suggests Partner Cloud for partners who resell your products, Data Cloud One for sharing data across your own orgs, and MuleSoft Anypoint or MuleSoft for Flow for other cases. Test the replacement in a sandbox that does not have S2S configured. Running both side by side can create duplicate records.

The Timeline

Salesforce's retirement article and the Winter '27 release update set out three phases:

Release	What changes
Spring '26	You can no longer turn S2S on. Orgs that already had it keep it working
Summer '26	No more bug fixes or enhancements. You can still log support cases
Spring '27	S2S is fully retired in all orgs and no longer functions

The Spring '27 date is not a single day. Like any feature tied to a major release, it changes when your instance is upgraded to Spring '27. Salesforce's release update tells you how to find that date: go to Trust Status, search for your My Domain name or instance, and open the Maintenance tab. Salesforce had not published the Spring '27 upgrade weekends when I wrote this, so check again once it does.

Sandboxes on a preview instance get each major release weeks before production. If you have a sandbox that still has an S2S connection, it should be the first place you see the retirement take effect.

The retirement also appears in Setup. From Setup, enter Release Updates in the Quick Find box and select Release Updates. The entry is Salesforce to Salesforce Is Being Retired.

Step 1: Check Whether Your Org Uses It

You do not need to open Setup to find out. S2S has its own objects, and they only exist in an org where S2S has been enabled. Salesforce's object reference says so directly: "If the organization does not have Salesforce to Salesforce enabled, the PartnerNetworkConnection object is not available."

That makes the query from the Quick Answer a reliable test:

sf data query --target-org my-org --query "SELECT Id, ConnectionName, ConnectionStatus, ConnectionType, ResponseDate FROM PartnerNetworkConnection"

Here is what my own Developer Edition org returns, because it never had S2S switched on:

ERROR at Row:1:Column:50
sObject type 'PartnerNetworkConnection' is not supported.

That error is the good outcome. It means there is nothing to migrate in that org. Run the same query against every production org you own, including orgs from acquisitions and orgs a business unit runs on its own, since those are where S2S tends to survive.

If you prefer Setup, enter Salesforce to Salesforce in the Quick Find box and open Salesforce to Salesforce Settings. In an org that uses it, the Connections tab in Salesforce Classic lists every connection.

Step 2: List the Connections and What They Share

If the query returned rows, each row is one connection to another org. ConnectionStatus tells you its state. The values you will care about most are Accepted (live), Inactive (deactivated) and Sent or Pending (an invitation that was never completed). ConnectionType is Standard for normal S2S sharing and Replication for an Organization Sync connection.

A connection being accepted does not mean it is still used. To see what each connection actually shares, query the records it forwards:

sf data query --target-org my-org --query "SELECT ConnectionId, Status, COUNT(Id) shared, MAX(StartDate) lastAccepted FROM PartnerNetworkRecordConnection GROUP BY ConnectionId, Status"

PartnerNetworkRecordConnection holds one row for each record shared over a connection. Status shows whether the share is active and in which direction (Active (sent) or Active (received)), or inactive. StartDate is when the other side accepted the record, so the latest one tells you how recently the connection did anything.

Use the results to sort your connections into three groups:

1. Accepted, with records accepted recently. This is live and needs a replacement.
2. Accepted, with nothing recent. Ask the business owner whether anyone still expects it to work. If not, there is nothing to replace.
3. Inactive, sent or pending. Nothing flows through these. Record them in your inventory and move on.

For each live connection, write down the other org's owner (the connection links to an AccountId and ContactId in your org), the objects it shares, the direction, and the business process it supports. That list is what you take into Step 4.

Step 3: Find What Depends on It

The connection itself is only part of the work. S2S is often driven by something else, and those things fail when S2S stops.

Apex and triggers. Forwarding records automatically is usually done in Apex, by inserting PartnerNetworkRecordConnection records with a ConnectionId and LocalRecordId. Retrieve your code and search it:

sf project retrieve start --metadata ApexClass ApexTrigger Flow --target-org my-org
grep -rl -E "PartnerNetwork|ConnectionReceivedId|ConnectionSentId" force-app

Any file in the result references S2S. Code that queries or inserts these objects is a runtime dependency, so plan to remove or replace it as part of the migration rather than after it.

Integrations and data pipelines. In orgs with S2S enabled, shared objects can carry connection fields such as ConnectionReceivedId and ConnectionSentId. A data warehouse sync or ETL job that selects every field can include them without anyone choosing to. Salesforce has not said what happens to those fields after the retirement, so check your integration mappings for them and be ready to drop them.

Reports and list views. The same connection fields can be used as columns and filters, for example in a view of leads received from a partner. Those are often how a team works with S2S records day to day, and they are easy to miss in a code search.

Salesforce Connect's cross-org adapter, if you use it. This is a different feature, but it is also retiring something in Spring '27. Its password and OAuth 2.0 authentication methods depend on the SOAP login() call, which is being retired, and Salesforce's release update says to move cross-org external data sources to named credentials. If your org-to-org setup uses both features, plan both changes together.

Step 4: Choose the Replacement

Salesforce's retirement article recommends an alternative for each use case:

What S2S does for you	Salesforce's suggestion
Shares information with partners who resell your products	Partner Cloud, which gives partners a branded portal with deal registration and controls on what they see
Shares data across several orgs your company operates	Data Cloud One, which unifies data across orgs with identity resolution and central governance
Anything else	MuleSoft Anypoint for a full integration platform, or MuleSoft for Flow, which adds integrations to Flow Builder and can connect two Salesforce orgs

Not sure which applies? Answer two or three questions about one connection and the tree gives you the replacement Salesforce suggests for it.

Three things are worth knowing before you choose.

None of them is a drop-in replacement. Partner Cloud and Data Cloud One are larger products than S2S. Salesforce compares them to S2S on features such as partner portals, deal registration and identity resolution, which S2S never had. If all your connection does is copy leads one way, you are choosing a product that does much more than you need, and the size of the change should be planned for.

All of them cost money. Salesforce's article says the alternatives "have some license or cost impact" and tells you to contact your account executive for details. Procurement and approval usually take longer than building the replacement. Start that conversation as soon as you know a connection is live.

Do not run both side by side in production. Salesforce says you can run S2S alongside an alternative but "may notice duplicate data in one or more orgs", and recommends testing in a sandbox that does not have S2S configured. Build and test the replacement there, then switch the business process over in one move.

Step 5: Plan the Switch-Over

Work back from your instance's Spring '27 upgrade weekend:

1. Now: run the Step 1 query in every org, and list the live connections from Step 2.
2. Next: agree the replacement and its budget for each live connection, and tell the partner or business unit on the other side. They have to change their side too.
3. Before the release: build and test the replacement in a sandbox without S2S, remove the Apex and automation from Step 3, and update integration mappings and reports.
4. Switch over: move the business process to the replacement and deactivate the S2S connection yourself, before the release does it for you. That way you control the day it changes.

Keep the inventory from Step 2. Once S2S is retired the objects may not be queryable any more, and the list of what was shared with whom is the record you need if a partner later asks.

Frequently Asked Questions

Q: When exactly does Salesforce to Salesforce stop working?

A: With the Spring '27 release, on the weekend your instance is upgraded. That date differs between instances. Find yours on Trust Status by searching for your My Domain name or instance and opening the Maintenance tab. Salesforce had not published the Spring '27 dates when this was written. Sandboxes on a preview instance are upgraded earlier, so they are where it stops first.

Q: Can I re-enable S2S or keep it running a bit longer?

A: No. Since Spring '26 S2S cannot be switched on in an org, and with Spring '27 it no longer functions anywhere. Unlike some release updates, there is nothing to postpone. The only choice is what replaces it and when you switch.

Q: Will Apex that references PartnerNetworkConnection break?

A: Plan for it to. Salesforce's documentation says these objects are not available in an org without S2S enabled, and code that queries or inserts an object that is not available fails. Salesforce has not published exactly what happens to existing code at retirement, so the safe course is to find every reference with the search in Step 3 and remove it as part of the migration.

Q: What about Organization Sync?

A: Organization Sync uses the same object, with ConnectionType set to Replication. Salesforce's S2S retirement article does not mention Organization Sync by name. If any of your connections are replication connections, ask Salesforce Support directly how the retirement affects them, rather than assuming either way.

Q: Is Salesforce Connect's cross-org adapter a replacement?

A: It is not on Salesforce's list of suggested alternatives. It also works differently: the cross-org adapter lets one org read another's records as external objects, rather than copying records across. That suits some read-only cases. If you use it, note that its password and OAuth 2.0 authentication are also being retired in Spring '27, and it needs to move to named credentials.

Key Takeaways

• S2S stops functioning in every org with Spring '27, on your instance's upgrade weekend. There is no extension and no migration tool.
• A query on PartnerNetworkConnection tells you whether you are affected. If the object does not exist, S2S was never enabled.
• List connections, then the records they share, because an accepted connection is not necessarily a used one.
• Search code, integrations and reports for PartnerNetwork, ConnectionReceivedId and ConnectionSentId. Those break along with the connection.
• Every suggested replacement has a licence cost, so the budget conversation is the long pole. Start it now.

What's Next?

Run the Step 1 query against every org you own this week. Most will return the error, and those are done. For the ones that return rows, take the Step 2 inventory to the business owners and your account executive, because the replacement is a product decision as much as a technical one.

Several other retirements land around the same time: the username-password and user-agent OAuth flows retire on 20 February 2027, and the SOAP login() retirement is behind the cross-org adapter change. If you are reviewing integrations for one of these, check them against all of them in the same pass.

Resources & References

• Salesforce-to-Salesforce Retirement, Salesforce Help knowledge article 005103355, for the timeline, alternatives and comparisons
• Salesforce to Salesforce Is Being Retired (Release Update), Winter '27 release notes
• Salesforce Connect Cross-Org Adapter Legacy Authentication Is Being Retired (Release Update), Winter '27 release notes
• PartnerNetworkConnection and PartnerNetworkRecordConnection, Object Reference for the Salesforce Platform
• Trust Status, for your instance's Spring '27 upgrade date
• Salesforce Security Enforcement 2026: The Complete Guide, for the other changes landing around the same time