Salesforce-to-Salesforce Retirement: Spring 2027 Migration Guide

Salesforce-to-Salesforce Retirement: Spring 2027 Migration Guide

Salesforce-to-Salesforce (S2S) is being retired. Every existing S2S connection will stop functioning, every shared record will stop syncing, and every automation built on PartnerNetworkRecordId or ConnectionReceivedId will break. There is no automated migration path to any replacement.

If your organization relies on S2S to share leads, opportunities, cases, or custom objects between separate Salesforce orgs, you need to design, build, and deploy a completely new integration architecture before Spring 2027.

S2S was a free, point-and-click pub/sub utility. Its replacements — Partner Cloud, Data Cloud, and MuleSoft — are premium products requiring distinct data models, significant licensing costs, and complex implementation cycles. Moving off S2S is not an upgrade; it is a forced re-architecture of your multi-org data strategy.

This guide covers the phased retirement timeline, what breaks when S2S goes dark, how to audit your current usage, and how to evaluate the replacement options based on your actual use case.

What Is the Salesforce-to-Salesforce (S2S) Spring '27 Retirement?

Salesforce-to-Salesforce was a native feature that let two Salesforce orgs establish a trusted connection and share records — leads, opportunities, accounts, cases, and custom objects — in near real time. It operated on a publish/subscribe model with field-level mapping. Org A published a record, Org B subscribed to it, and Salesforce handled background synchronization via the PartnerNetworkRecordConnection object, a hidden junction object that tracked LocalRecordId, PartnerRecordId, and Status for each shared record.

Salesforce announced the retirement in the Summer '26 release notes. The retirement is phased:

This timeline comes directly from Salesforce's official retirement knowledge article, which states that "in the Spring '27 major release, Salesforce to Salesforce will be fully retired in all orgs and will no longer function."

When full retirement occurs, the underlying infrastructure powering S2S is turned off. The PartnerNetworkRecordConnection object becomes inaccessible. Real-time sync halts immediately, silently cutting off data flow between partner portals, franchisors and franchisees, and multi-org enterprise deployments. Sandbox orgs are also affected — S2S connections in sandbox environments will stop functioning on the same Spring '27 schedule, which means testing your replacement architecture requires building it in a sandbox configured without S2S from the start.

Why S2S Is Retiring: The Shift to Modern Data Architecture

S2S represented a legacy approach to data integration: point-to-point, tightly coupled synchronization between pairs of orgs. It relied on the PartnerNetworkRecordConnection junction object and manual field mapping to keep two distinct relational databases aligned. There was no identity resolution, no native deduplication, and no centralized governance.

As organizations scaled beyond two or three org pairs, this created significant technical debt. Connections formed a spiderweb topology that was difficult to monitor, prone to silent failures when a validation rule changed in the target org, and impossible to govern centrally. The feature was never designed for the multi-org complexity that enterprises now operate.

Salesforce's architecture team noted in their Summer '26 architect highlights blog post that S2S "was often used as a low-friction shortcut for scenarios that genuinely needed one of these more structured patterns."

The platform has moved toward three architectural patterns that S2S was never built to support:

• Centralized data lakehouses (Salesforce Data Cloud) with harmonized identity resolution across multiple orgs
• API-led connectivity (MuleSoft) with transformation, orchestration, and error handling
• Purpose-built PRM (Partner Cloud) with branded portals, deal registration, and partner enablement

Instead of physically copying a record from Org A to Org B and trying to keep them synced via a hidden object, the modern approach either harmonizes data conceptually using Data Cloud (leaving records in their source orgs) or orchestrates data flow via managed APIs using MuleSoft. Both approaches reduce data duplication and provide clearer data lineage — but both require fundamentally different implementation approaches and budgets.

Replacement Options: Comparison at a Glance

Because S2S served multiple distinct use cases — channel sales, multi-org enterprise architecture, and everything in between — there is no single replacement. Before reviewing each option in depth, use this table to orient your decision:

Cost ranges are estimates derived from published list pricing, partner community benchmarks, and Gartner Peer Insights data as of mid-2026. All enterprise software pricing is negotiated; treat these as planning ranges, not quotes.

Decision Tree: Choosing Your Replacement Path

Most S2S use cases can be routed to the correct replacement by answering three questions:

Question 1: Is the counterparty an external channel partner (reseller, distributor, franchisee) or an internal org (business unit, subsidiary, acquired company)?

• External partner → Evaluate Partner Cloud first
• Internal org → Proceed to Question 2

Question 2: How many orgs are involved, and do you need a unified customer view across them, or do you need to move records and trigger workflows?

• Unified customer view across 2+ internal orgs → Evaluate Salesforce Data Cloud
• Record movement and workflow orchestration → Proceed to Question 3

Question 3: What is your data volume and system complexity?

• High volume (10,000+ records/day) or involves non-Salesforce systems (SAP, Oracle) → MuleSoft Anypoint Platform
• Low-to-medium volume, Salesforce-only, admin-maintainable → MuleSoft for Flow or Custom REST API

Evaluating the Official Replacements

Partner Cloud — For Channel Sales and Partner Collaboration

Best fit: Organizations that used S2S primarily to share leads, opportunities, or deal data with reseller or channel partners.

Partner Cloud is Salesforce's recommended replacement for partner/channel management. It provides a full Partner Relationship Management (PRM) experience built on Experience Cloud, with branded partner portals, native deal registration, co-selling workflows, and built-in partner performance analytics.

Instead of syncing records into a partner's separate Salesforce org, you invite the partner into a branded, secure portal connected directly to your core org. The partner accesses your data via a controlled portal interface rather than having a separate copy of the record in their own org.

Typical implementation timeline: 6–12 weeks for a mid-sized channel program with 10–50 partner companies and standard deal registration workflows. More complex programs (tiered partner levels, custom co-selling logic, partner-facing analytics) extend to 16–24 weeks.

Key trade-off: Partner Cloud is a fundamentally different product category from S2S. If you used S2S to push a handful of leads to a partner's org, Partner Cloud may be more infrastructure than you need — you're licensing and configuring a full PRM platform. If you were stretching S2S to run a channel program, Partner Cloud is the correct architectural replacement. The critical difference: your partners work out of your portal, not their own CRM. For partners who need to work natively in their own Salesforce org, this creates an adoption friction that S2S did not.

Salesforce Data Cloud — For Multi-Org Data Unification

Naming clarification: Salesforce has marketed this product under several names ("Customer Data Platform," "Data Cloud," "Data Cloud One"). The current product name as of the Summer '26 release cycle is Salesforce Data Cloud. "Data Cloud One" appears in some Salesforce marketing materials as a packaging description for unified enterprise deployment. When evaluating this option with your AE, ask specifically about Data Cloud and the Data Cloud for Orgs connector.

Best fit: Enterprises operating multiple internal Salesforce orgs — holding companies, post-M&A scenarios, or organizations running distinct Sales and Service orgs — that need a unified customer profile across org boundaries without physically copying records.

Data Cloud uses a centralized data lakehouse architecture. Where S2S copied records between org pairs, Data Cloud ingests data from all connected orgs as data streams, maps fields to standardized Data Model Objects (DMOs), resolves identity across org boundaries using configurable match rules (email, phone, Salesforce ID), and creates unified profiles. "Activation" in Data Cloud terminology means pushing those unified profiles or segments back to connected orgs, ad platforms, or other destinations — it is not real-time record sync; it is profile-based data distribution.

Typical implementation timeline: 3–6 months for a two-org unification project with standard identity resolution. Multi-org deployments (5+ orgs) with complex data models and custom identity resolution logic run 6–12 months.

Key trade-off: Data Cloud does not replicate the record-level, field-level sync that S2S provided. It creates unified views and distributes profile data. If your S2S use case was "when Org A updates an Opportunity stage, Org B should see the update in that Opportunity record," Data Cloud is not the right replacement — MuleSoft or a custom API is. Data Cloud is the right answer if you need "show me a single view of this customer across all our orgs."

Cost: Data Cloud is licensed separately from core Salesforce. Published list pricing starts at approximately $108,000/year for enterprise-tier Data Cloud with standard data volume allotments. Smaller packages exist but typically don't cover the data volumes involved in multi-org consolidation. Gartner Peer Insights reviewers consistently note that actual negotiated contracts for mid-market deployments run $30,000–$80,000/year. This is a significant jump from the $0 cost of S2S.

MuleSoft Anypoint Platform — For Complex Integration Scenarios

Best fit: High-volume, bidirectional, multi-system integrations that require transformation, routing, error handling, and orchestration — especially when non-Salesforce systems are involved.

MuleSoft Anypoint is the right path when your S2S usage was a workaround for what should have been a proper middleware layer. If you're syncing data between Salesforce orgs alongside SAP, Oracle, or other non-Salesforce systems, or if you need guaranteed delivery, retry logic, and transformation of record payloads, MuleSoft provides the integration backbone.

Pricing model: Salesforce migrated MuleSoft to a consumption-based model (Mule Flows and Messages rather than the legacy vCore model) beginning in 2024. All pricing is quote-based. Published benchmarks from Vendr's 2025 SaaS pricing report place the median MuleSoft Anypoint contract at approximately $60,000/year for mid-market buyers; complex enterprise deployments with high message volumes reach $150,000–$250,000+. Implementation costs (internal developer time or SI partner fees) add 50–150% on top of licensing in year one.

Typical implementation timeline: 3–9 months depending on the number of integration flows, data transformation complexity, and whether existing MuleSoft infrastructure can be extended.

Key trade-off: MuleSoft requires specialized integration developers to build and maintain the API flows. It is not an admin-led tool. If you choose this path for S2S replacement, plan for ongoing developer ownership of the integration layer.

MuleSoft for Flow — For Admin-Led, Lighter-Weight Integration

Best fit: Process-level integrations between Salesforce orgs that don't need the full Anypoint Platform, where an admin can own the configuration.

MuleSoft for Flow embeds integration capabilities directly within Salesforce Flow Builder using pre-built connectors. It's designed for admin-led scenarios — connecting two Salesforce orgs for specific workflow handoffs without requiring a MuleSoft developer or separate Anypoint infrastructure.

Typical implementation timeline: 4–8 weeks for simple org-to-org workflow triggers.

Key trade-off: Lower complexity and lower cost than Anypoint, but also lower capability. MuleSoft for Flow handles point-to-point workflow triggers well. It does not handle high-volume batch sync, complex transformation, or multi-system orchestration. If your integration needs grow, you will eventually need Anypoint.

Custom REST API Integration — The Fallback

Salesforce does not list this as an official alternative, but many teams will build custom point-to-point integrations using the Salesforce REST API with OAuth 2.0 authentication and Connected Apps. This involves Apex callouts (or external middleware), webhooks, and state management to replicate what S2S did natively.

Typical implementation timeline: 4–10 weeks for a simple unidirectional sync; 8–16 weeks for bidirectional sync with conflict resolution.

Key trade-off: You own the maintenance — error handling, retry logic, conflict resolution, governor limit management, and monitoring. You must handle the scenarios S2S abstracted away: what happens when the target org is down? When a required field is added to the target? When a record fails validation? These failures are silent without explicit monitoring. This path is appropriate for low-volume, stable integrations (under ~1,000 records/day) where licensing cost is the primary constraint.

The Hidden Risks: What Breaks When S2S Stops Syncing

Migrating off S2S is not just about replacing a feature. It's about refactoring the metadata and automations that depend on S2S architecture. When Spring '27 arrives, the failure cascade hits several specific areas simultaneously.

Records Stop Syncing — Split-Brain Data

Every record currently being shared between connected orgs goes stale at the moment S2S retires. The receiving org retains its local copy, but updates from the source org stop flowing. If a user updates an Opportunity stage in Org A, Org B retains stale data indefinitely. If users in both orgs update their respective copies after cutover, you create data conflicts with no automated resolution path.

Partner-facing dashboards, territory assignments, and pipeline forecasts built on S2S-synced data become a snapshot frozen in time.

Your migration plan must include a hard cutover date where S2S is deactivated and the new integration takes over immediately to prevent split-brain data scenarios from accumulating.

Connection Objects Become Inaccessible — Export Before Spring '27

S2S tracks shared records using the PartnerNetworkRecordConnection object, which holds the LocalRecordId, PartnerRecordId, and Status of each sync. When S2S retires, this object and all related S2S metadata become inaccessible.

Action required before Spring '27: Export your complete PartnerNetworkRecordConnection data via Data Loader using the query below. This is the only way to retain an audit trail of what was shared, with which orgs, and when. Once the object becomes inaccessible, this data cannot be recovered.

SELECT Id, LocalRecordId, PartnerRecordId, Status, ConnectionId, CreatedDate, LastModifiedDate
FROM PartnerNetworkRecordConnection
ORDER BY CreatedDate DESC

Any custom reporting built on this object will break. Any SOQL queries referencing it in Apex will fail to execute. Export the data, archive it, and then plan your reporting migration.

Automation Breaks — Silent Failures Are the Most Dangerous

This is the highest-risk failure mode. Some automations will fail loudly: Apex classes referencing deprecated S2S fields will fail to compile. Flows will throw unhandled faults with explicit error logs. These are recoverable at cutover.

The dangerous failures are silent. Triggers and Flows that fire on record changes from S2S-synced fields won't throw errors — they simply stop receiving the data changes that triggered them. The automation continues to run, but on stale input data. You get no error log. You get bad data downstream, potentially for days or weeks before someone notices.

Common automation patterns that break silently:

• Apex triggers that check ConnectionReceivedId IS NOT NULL to determine if a record originated from a partner org and route it to a specific queue — the field is never populated, so routing logic never fires
• Validation rules referencing PartnerNetworkRecordId — the field is empty, but the rule still evaluates
• Flows that trigger on updates to fields populated by S2S sync — changes stop arriving, Flow never fires
• Roll-up summaries or reports aggregating data from S2S-synced records — counts and amounts become incorrect as synced records stop updating
• Scheduled jobs processing records based on S2S connection status — the status field is stale

Common automation patterns that break loudly (compile/runtime errors):

• Apex classes with direct SOQL against PartnerNetworkRecordConnection or PartnerNetworkConnection — these will fail at runtime when the object is retired
• Flows with explicit references to S2S objects in Get Records elements

You must rewrite all of these automations to reference your new integration architecture before Spring '27. For example, replacing ConnectionReceivedId IS NOT NULL routing logic with a check against a custom External_System_ID__c field populated by your new integration.

Undocumented Dependencies Surface Under Load

Many organizations built secondary workflows around S2S-synced data without explicit documentation. Common examples: a case routing rule that assigns based on a field synced from a partner org; a lead scoring model that uses partner activity data; an escalation path that triggers when a shared opportunity status changes. These dependencies only surface when data stops flowing.

Plan for a discovery period during your audit — not just a metadata search, but interviews with sales ops, support ops, and partner team leads about what data they depend on and where it comes from.

How to Audit Your Current Salesforce-to-Salesforce Usage

Before selecting a replacement architecture, you need a complete inventory of what S2S is doing in your org. Many connections were set up years ago by administrators who have since left.

Step 1: Check for Active Connections

Navigate to Setup → Salesforce to Salesforce → Connections. Document every active connection: the partner org name, the connection status (Active/Inactive), the date last active, and the business owner for that partner relationship.

Step 2: Map Published and Subscribed Objects

For each active connection, click into the detail page. Document exactly which standard and custom objects are being published (sent outbound) and subscribed (received inbound), including the field-level mappings for each object. This mapping document becomes the specification for your new integration.

Step 3: Find Automation That References S2S Objects

Search your org's metadata for references to S2S-specific identifiers:

-- Find Apex classes referencing S2S objects or fields
SELECT Id, Name FROM ApexClass 
WHERE Body LIKE '%PartnerNetwork%' 
   OR Body LIKE '%ConnectionReceived%'
   OR Body LIKE '%PartnerNetworkRecordId%'

Also search:

• Flow Builder — search for PartnerNetworkRecordId and ConnectionReceivedId in resource and element references
• Process Builder (legacy) — identical field references
• Workflow Rules — field update triggers on S2S-populated fields
• Validation Rules — formula references to S2S fields
• Reports and Dashboards — filters on ConnectionReceivedId, PartnerNetworkRecordId, or connection status fields

For a comprehensive metadata search, use VS Code with the Salesforce Extensions pack or a metadata search tool like Metazoa or Elements.cloud to search your full org metadata for PartnerNetworkRecordConnection, ConnectionReceivedId, and PartnerNetworkRecordId across all metadata types simultaneously.

Step 4: Document Data Volume and Sync Direction

For each connection, quantify:

• Total records currently shared (run a COUNT on PartnerNetworkRecordConnection filtered by ConnectionId)
• Daily/weekly sync volume (query on CreatedDate and LastModifiedDate)
• Sync direction: unidirectional (publish only or subscribe only) or bidirectional
• Whether custom objects are involved

High-volume syncs require bulk API patterns in the replacement architecture to avoid governor limits. A connection sharing 50 leads/month with a single partner has fundamentally different replacement requirements than one syncing 10,000 cases/day across five orgs. The former might be correctly replaced by a custom REST API integration; the latter requires Anypoint.

Step 5: Identify Downstream Consumers

Map which teams, processes, and systems consume S2S-synced data. Sales operations using partner-sourced leads? Support teams routing cases to partner orgs? Finance rolling up partner revenue across org boundaries? Each downstream consumer needs to be accounted for in the replacement architecture's data model.

Step 6: Assess ISV and Managed Package Dependencies

If your org runs any managed packages, check whether those packages use S2S internally. ISV packages occasionally used S2S for cross-org data sharing between subscriber orgs and vendor orgs. Contact the package vendor directly to confirm whether their managed package depends on S2S and whether they have issued updated package versions that use alternative integration patterns. Managed package S2S dependencies cannot be patched by your admin team — they require a vendor-provided update.

Building Your Migration Strategy

With your audit complete, the migration pattern depends on your use case. In all cases, Salesforce recommends "testing and validation in a sandbox environment without Salesforce to Salesforce configured, to validate the data sharing approach and ensure business continuity." This means your replacement integration must be built and validated in a sandbox configured without S2S before any production cutover.

For Partner/Channel Scenarios → Partner Cloud

1. Inventory all S2S connections used for partner data sharing and quantify the partner count and record volumes involved
2. Evaluate whether Partner Cloud's PRM capabilities match your needs — or exceed them at a cost you can justify
3. Provision a Partner Cloud sandbox and configure partner portal experiences in Experience Cloud
4. Rebuild field mappings as Partner Cloud sharing rules and portal page layouts
5. Migrate partner-facing automations (deal registration flows, lead distribution rules) to the new data model
6. Run parallel for one full business cycle — typically 30 days for a monthly sales cadence — before disabling S2S

For Multi-Org Unification → Salesforce Data Cloud

1. Map all S2S connections that share customer, account, or contact data across internal orgs
2. Design your Data Cloud data model: map source org fields to DMOs (Individual, Sales Order, Contact Point, etc.)
3. Configure data streams from each contributing org using the Salesforce CRM connector
4. Configure identity resolution rules: define match criteria (email exact match, phone normalized match, Salesforce ID) and reconciliation rules for attribute priority
5. Build and test unified profiles in a Data Cloud sandbox
6. Re-point downstream reports, dashboards, and automations to unified profile data via Data Cloud-connected queries or activation targets
7. Validate data quality against your existing S2S data as a baseline before cutover

For Complex Integration → MuleSoft Anypoint or Custom API

1. Document integration patterns: sync frequency, record volume, transformation requirements, error handling requirements
2. Design API contracts for each data flow, including error response schemas and retry behavior
3. Build integration flows with explicit error handling, retry logic with exponential backoff, and dead-letter queue handling
4. Implement monitoring and alerting for sync failures — MuleSoft Anypoint includes native monitoring; custom REST integrations require external monitoring (Datadog, New Relic, or Salesforce Health Cloud alerts)
5. Load-test against production volumes before cutover
6. Cutover with a parallel-run period (minimum two weeks) to validate data integrity against S2S baseline

Planning Your Migration with ClonePartner

S2S retirement is a forced re-architecture of your inter-org data sharing strategy. It is not a settings change — it is a data model migration, an automation rebuild, and a licensing decision rolled into one project with a hard deadline.

If your engineering team attempts to handle this by exporting CSVs or writing quick custom webhooks without addressing the underlying automation dependencies, you risk orphaning historical activities, breaking downstream partner operations, and accumulating stale split-brain data that is expensive to reconcile after the fact.

Organizations we work with typically discover S2S complexity as part of a broader migration — consolidating Salesforce orgs, migrating to Salesforce from another CRM, or redesigning their integration architecture. The S2S retirement adds a layer that most teams don't plan for until connections start breaking.

What ClonePartner brings to this:

• Mapping legacy S2S objects to modern patterns. We translate PartnerNetworkRecordId and ConnectionReceivedId references into the appropriate replacement architecture — whether that's Partner Cloud sharing rules, Data Cloud data streams, or MuleSoft API flows.
• Rebuilding dependent automation. Every Apex trigger, Flow, and report that referenced S2S-specific objects needs to be rebuilt against the new integration pattern. We handle the full automation audit and rebuild.
• Zero-downtime cutover. Partner portals and multi-org workflows can't go dark during migration. We design cutover plans that keep data flowing throughout the transition.
• Architecture right-sizing. Not every S2S connection needs a $60,000/year MuleSoft subscription. We help you match the replacement to the actual complexity — sometimes that's a custom REST API integration for a low-volume partner sync, and Anypoint only where the volume and complexity demand it.