Data movement between Salesforce orgs

Options for Data Movement Between Salesforce Orgs

There are many scenarios where data may need to move between two Salesforce orgs, and similarly, there are several options available when it comes to syncing data between Salesforce orgs.

Take for example a scenario where company ABC has acquired company XYZ. The two companies are in the same industry, servicing very similar clients, so there is a significant overlap between Leads, Contacts and Accounts between the two Salesforce orgs. The following are potential options for moving the data between the two orgs:

Salesforce to Salesforce (S2S)

What it is: With Salesforce to Salesforce, an org can have a published object (what it exposes to other orgs) and subscribed objects (what it can get from other orgs). It is included out-of-the-box for most Salesforce editions and takes only a few minutes to set up.

How it works: Records from one org can be ‘forwarded’ to another org. Changes on the record in the publishing org (where the record originates) are reflected in the record in the subscribing org. Users can forward a single record from the related list or in bulk through a list view. Both of these ways only work in Salesforce Classic and users will need to switch back from Salesforce Lightning to classic for this action.

When to use:

  • In this scenario, the use case is fairly limited. For example, if weekly or monthly, you want to send a large list of leads between orgs or if you want to send single records at a time.
    Your standard objects are limited to Account, Attachment, Case, Contact, Lead, Opportunity, Product and Tasks.

When not to use:

  • You want a real-time two-way sync between orgs
  • You do not want users to switch between Salesforce Classic and Lightning
  • The standard objects you want to have syncing are not supported with Salesforce to Salesforce

Salesforce Connect

What it is: With Salesforce Connect, data doesn’t come into the Salesforce org. Instead, it allows users to view, search and modify data in an external Salesforce org. It is an additional product that needs to be purchased.

How it works: The data would exist as a custom object – as an example, an admin would create an external object for the Lead object. Setting up Salesforce Connect is relatively simple and uses point-and-click config.

When to use:

  • You want a simple to configure solution
  • You don’t want the data to reside in the Salesforce org

When not to use:

  • You want the data to reside in Salesforce org
  • You want to use the same object for the orgs
  • You don’t want to pay additional license fees

AppExchange Products

What it is: Many AppExchange products let you sync data between Salesforce orgs. Plus, these tools often offer additional features, such as merging duplicates.

How it works: Set up field mappings and filter criteria on what data needs to be synced. Jobs can be manually executed to run, or you can set up scheduled jobs to run.

When to use:

  • You have a complex use case not solved by Salesforce to Salesforce or Salesforce Connect
  • You don’t want to have custom code or build complicated solutions and would prefer a plug-and-play tool

When not to use:

  • Cost is a concern and you don’t want to pay additional license fees

Custom REST APIs

What it is: As always, there is an option to build custom REST APIs with Salesforce to manage data transfers. Each org can set up connected apps to expose endpoints

How it works: Set up the criteria to sync your records. For example, all records modified within the last hour in either org. Set up a scheduled job that updates records between orgs at a time interval that makes sense for your use case.

When to use:

  • You have a use case that isn’t solved with the other options – for example, complicated filter criteria on what needs to be synced or complex data transformations during the sync process

When not to use:

  • Long-term maintenance costs are a significant consideration


Salesforce to Salesforce, Salesforce Connect, AppExchange Tools, and Custom Rest APIs are all viable options for moving data between Salesforce orgs. Which method you choose will rely heavily on your own organization’s needs, and specifically your budget and timing.

Tool Cost Time to
Deploy Solution
Available in
Salesforce to Salesforce
Free Short No
Salesforce Connect Add-On Product


Short Yes
AppExchange Tools License Fees


Short Yes
Custom REST APIs Time intensive
High maintenance cost
Medium Yes


Have questions, or want to know more about the best way for your organization to move Salesforce data? Get in touch! We’d love to chat with you.


You may be interested in

Approaches for Salesforce Org Mergers. Image of three consoles merging into one

Approaches for Salesforce Org Mergers

Imagine this scenario: Two separate companies have heavily customized Salesforce orgs that work perfectly for their own respective business needs. Then, one company acquires the other company.  Overview The Two Approaches Lift-and-Shift Move-and-Improve (Optimization) The Third Rail It Isn’t Just Salesforce How CloudKettle Can Help What happens next? That’s a great question – and a […]

Read More

DevOps Guide for Salesforce

Salesforce DevOps Guide

What is DevOps? And why do you need it? DevOps consists of a set of practices and tools that makes it possible for an organization to produce applications and services more quickly than using conventional software development (Dev) and IT Operations (Ops) procedures in isolation. DevOps within Salesforce can be viewed in a very similar […]

Read More

Sign up for the latest tips & news from CloudKettle

Thank you for subscribing.