If two of your orgs share records through a connection nobody set up, this is for you. Salesforce is retiring that connection with Spring '27, and the part that hurts is quiet. This is not for you if your org has no named Salesforce admin or owner, or if one query below tells you the feature was never switched on.
What ends, and when?
Salesforce to Salesforce lets one org share records with another. It is the "Connections" feature, and in many orgs it was set up years ago by someone who has since left. Salesforce Help gives it three dates. From Spring '26 no org could switch it on. After Summer '26 it gets no fixes or enhancements, though support cases stay open. With Spring '27 it is retired in every org.
There is no single production date. Software Insights puts the cut-off at your instance's Spring '27 upgrade weekend, and sandboxes on a preview instance go first. Salesforce Ben has written "from January 2027" for the same change. Read your own instance on Trust, under Maintenance, and treat that as your date.
Does your org use it at all?
Ask the org. Open the Developer Console, then Query Editor, and run:
SELECT Id FROM PartnerNetworkConnection
If the answer is "sObject type 'PartnerNetworkConnection' is not supported", the feature was never enabled. The retirement does not touch you, and you can stop reading. If rows come back, each row is a connection to another org.
Two things follow when there are rows. The admin of the other org has to change their side too, so you cannot do this alone. And the record pairs, the list of which record in your org matches which record in theirs, live in PartnerNetworkRecordConnection. Export that before anyone deletes a connection. SFDC Developers suggests repeating the export right after you stop the connection, to catch pairs created in between.
What breaks without an error?
Some failures are loud. SFDC Developers says the connection objects only exist while the feature is on, so Apex, SOQL and Flow Get Records elements that read them fail at runtime. You will see those.
The quiet one is the bigger risk. Per the same source, a trigger or flow that only checks a field such as ConnectionReceivedId or ConnectionSentId raises no error. The field simply stops being filled, so the check never matches. The automation keeps running and never takes its branch. Records land with the wrong owner or the wrong status, and nothing logs a fault.
So search for more than connections: look for every flow, trigger and report that branches on those fields. Search your metadata for the field names before you decide anything.
Which do you move, replace or stop?
Give every connection one word. This is our rule, not a Salesforce rule. For each one ask what flows through it, and who in the other org depends on it.
Salesforce names four replacements: Partner Cloud, Data Cloud One, MuleSoft Anypoint and MuleSoft for Flow. It says each has "some license or cost impact", and it has not given prices in the article. Partner Cloud and Data Cloud One are larger products than the feature they replace, so they are not the default answer for a small share of records. Software Insights and SFDC Developers both say none has an automated migration path. You rebuild the sync and the logic that depends on it.
Salesforce also says to test the replacement in a sandbox without the feature configured. Running both together can duplicate records.
A connection with an owner and a clear answer is a task. A connection nobody can explain is the real problem, because the upgrade weekend will not wait for someone to be found. If the integration is a larger rebuild, our Salesforce integration work and the MuleSoft page cover that. If a sign-in change is also on your list, we wrote up the connected apps that stop on 20 February 2027.
What would we do first?
At Mindcat, we start a rescue week from this list. We get read-only access on day 1, run the query, export the record pairs, search the metadata for the connection fields, and write one line per connection: what flows through it, who owns it, who in the other org depends on it. The week ends with a written call per connection, with the reasons and the first fix. You can see a sample read on an invented org before you send us anything.
The assessment is free: a short read of the org and a written note. If you go ahead, the first build week is a fixed AED/SAR 14,900 (about USD 4,050), credited in full when you sign the build within 60 days. We do not fix-price a rescue we have not assessed.
Not for you if your org has no named Salesforce admin or owner, or if the query returned "not supported". Then there is nothing to decide.
