Tag Archives: data migration

A red arrow and a white arrow coming together and merging, representing a Salesforce org merge

Everything You Need to Know About Salesforce Org Merges

Salesforce org merges are complicated but often necessary processes that involve combining one or more production instances of Salesforce. In this blog, we discuss everything you need to know about them, including what they are, what they involve, and four reasons to merge Salesforce orgs. We’ll also list what information to gather before a Salesforce org consolidation, how to prepare for a merge, and we’ll discuss how to merge Salesforce instances.

What Are Salesforce Org Merges?

A red arrow and a white arrow coming together and merging, representing a Salesforce org merge

A Salesforce org merge or org consolidation occurs when a company decides to consolidate two or more instances of their Salesforce CRM. You combine the integration of the various technological backends of these orgs into a new whole. 

Oftentimes, these orgs are highly customized, with thousands of users, a significant amount of process automation, custom objects, Visualforce pages, Apex code, third-party apps, and more. Because of this, you have to sort through everything carefully to see what’s necessary and you need to keep, what you can improve, and what you no longer need.

What Does a Salesforce Org Merge Involve?

On the surface it sounds simple, but in reality, performing an org merge in Salesforce is highly complex. To do it correctly and to the benefit of your business, you have to decide how to merge two orgs with different processes, objects, fields, data, access levels, and so on.

An org merge tends to be a period of deep reflection and reevaluation of how you’ll leverage Salesforce to support the business’s growth going forward. 

Typically, you select one of the orgs as the surviving org. However, you might choose to combine multiple production instances of Salesforce into a new org. 

Either way, parts of the legacy org often survive the process. Perhaps the legacy org had a better solution for a shared business process or solved an issue that the surviving org never encountered. That’s why you need to merge any data you want to keep from the legacy org into the surviving org.

4 Reasons to Merge Salesforce Orgs

Because org merges are so involved, companies usually only perform them for four reasons: During a corporate acquisition, to reduce technical debt, to eliminate silos between teams, and to manage costs.

1. Corporate Acquisition Org Merge

A corporate acquisition is the most common reason for performing an org merge. When one company acquires another and they both use Salesforce as their CRM, they need to integrate their systems to fully integrate the company.

After the merge, there can only be one source of truth. That’s why you designate one Salesforce production instance as the surviving org.

2. Reduce Technical Debt

Another reason for merging Salesforce orgs is to reduce accumulated technical debt. Business changes rapidly, and decisions, processes, and workarounds that made sense last year might now be obsolete. When you perform an org merge, you can select what to keep, and what to discard.

In fact, companies that have accumulated significant Salesforce tech debt after years—or even decades—of using Salesforce may find it easier to start over fresh in a brand new org than try to unwind legacy processes. In this case, they save specific processes, optimize them, and move them to the new org. This is called the Greenfield approach.

3. Eliminate Silos Between Teams

At the same time, you might have originally had valid reasons for separate business units to operate in their own individual Salesforce orgs. However, today, it could be inhibiting greater collaboration.

4. Manage Costs

An org consolidation allows you to run your business more efficiently, because you can assign tasks across groups, run consolidated reports, and have one org as the single source of truth. You can also save money on duplicate license costs for any users who need access to both original orgs; plus, you have lower costs for setting up and managing the same or similar fields or processes in both instances. 

This is ultimately a considerable cost saver. Learn more on saving on Salesforce sandbox spend. 

Information to Gather for a Salesforce Org Consolidation

As we’ve discussed, a Salesforce org merge is a considerable undertaking. That’s why it’s wise to be as organized as possible before you begin. And good organization starts with information gathering. Answer the following questions:

  • What do you hope to gain from the org consolidation?
  • How many orgs do you need to merge? What are the editions of each?
  • Do the orgs have a Classic or Lightning Experience UI?
  • How many licenses are there in each org, and what types are they?
  • Will you add to or subtract from the current number and types of licenses?
  • Which third-party applications are currently installed in each org? What are their expiration or renewal dates? Which ones will you continue to use?
  • Do you have a predetermined surviving org?
  • Does the new org have sufficient file and data storage?
  • Which data are you consolidating? All of it, or only specific records and objects?
  • What duplicate content do you need to take into account?
  • What automations and integrations are in place in either org?
  • Will you need to provide training for users post merge?
  • Do you want to preserve change histories and stage histories?
  • How will you handle private views, dashboards, and reports?
  • Do you need to preserve system audit fields?
  • If there are inactive users, how do you want to handle them?
  • Do you need to update sharing rules for the surviving org?
  • Do you need to deploy special features like multi currency, multi language, or territory management?
  • What is your timeline for the project?
  • Do you have the resources in place to handle this merge project?

How to Merge Orgs in Salesforce

Each org merge project is unique and will have specific criteria for success, but the overall process is the same. Whether you complete the consolidation yourself or hire a consultant to do it, here’s how to merge orgs in Salesforce.

1. Prepare for the Org Consolidation

A. Create a Plan

Start by putting a plan in place, along with a realistic timeline. To determine your timeline, consider both your company’s needs, as well as license expiration dates. 

It can also be useful to establish a Salesforce Center of Excellence to lead the initiative.

B. Build Your Team

Org consolidation is not a one-person job. It’s critical to engage your stakeholders early in the process. In addition, make sure that each team that will be impacted by the org is represented. 

On the technical side, you’re going to need someone who understands the data structure of both orgs. This person should be able to make recommendations on the best way to map the data from the legacy org to the surviving org.

C. Assess What Systems the Merge Will Impact

Make a list of the systems the consolidation will impact. This will include your core Salesforce Clouds, as well as:

  • Additional Salesforce Products (Pardot, Field Service, etc.)
  • Custom objects
  • Apps from the AppExchange
  • Integrations to systems outside Salesforce (ERP, sales engagement, advertising platforms, web-to-lead/case forms, etc.)

D. Document Requirements

With all the information from the previous section  at your fingertips, it’s time to list out the requirements for the org merge. Think also about things such as the length of time you’ll need to store data from the legacy org that you’re not consolidating, how processes will change, and what your testing plan is.

E. Create an Org Merge Strategy

You absolutely need a strategy to effectively complete the consolidation. Due to their complexity, org merges take time and multiple sprints. However, that doesn’t mean all work in production grinds to a halt.


Determine which sandbox to use for staging the org merge before deploying it to production. How will you keep the staging environment current with changes and hotfixes in prod? Do you have an easy, repeatable way to seed the sandbox with data (and possibly even metadata) without having to do a refresh that overwrites the org merge work in progress?

2. Build Your ETL Logic

ETL (extract, transform, load) is the process of taking data out of one system, cleansing it, and moving it into a new system. Mapping out your ETL logic is the key to a seamless org merge, so make sure to allocate this step the time and attention it deserves.

A. Map Objects Between the Two Orgs

Start by mapping objects between the surviving org and legacy org. Which objects do both orgs have in common? Which legacy objects will need to be mapped to existing objects in the surviving org? Will new objects need to be created in the surviving org so you don’t lose data?

Also, consider which objects should use audit fields for accurate reporting. For instance, if you’re not careful with Opportunities, you could make it appear that you created and closed the legacy Opportunities on the same day. This would completely invalidate your average sales cycle.

B. Check Field-Level Mapping

Now you’ve mapped the objects, it’s time to think about field-level mapping. Now the objects match, do their fields? 

If not, is the data needed in the surviving org? If so, should the field be mapped to an existing field or recreated in the surviving org?

Pay attention to picklist values and any data standardization in the surviving org. Loading incorrect formats or values will impact reporting, validation rules, and general user experience. 

For example, let’s say the surviving org uses Enterprise Territory Management to assign territories based on a two-letter state or province code. In this case, the legacy values should be transformed before loading, otherwise the legacy accounts won’t be assigned correctly in the surviving org. 

3. Execute the Org Merge

With all the preparations complete, it’s time to perform the actual merge process. Remember: You’ll need to keep the legacy org operational until you’re ready to fully transition users to the surviving org. This means you’ll have to run through the org merge steps multiple times to make sure you’ve caught all new and updated records.

A. Steps for Executing an Org Merge in Salesforce

Perform the following steps to carry out the org consolidation process:

  1. Provision a sandbox from your surviving org, seeding any data from the surviving org if needed.
  2. Configure any new objects, fields, and apps that you need in the surviving org.
  3. Extract and load your legacy data into the sandbox, transforming it per your ETL logic.
  4. Test, test, test! This should include unit testing and UAT in the sandbox. 
  5. Train users on any changes to processes.
  6. Deploy your metadata changes and records to production. 
  7. Review all deployments. Remedy any errors, and redeploy if necessary.

Congratulations! You have successfully completed the org merge!

A Final Word

Keep in mind that the type of integration needed and your stakeholders’ requirements will dictate when you can start making changes. The earlier you can transition integrations that create or update records, the fewer times you’ll have to run through the org merge process. 

However, this isn’t always possible. For instance, you can’t update your legacy web-to-case forms until you have users who can resolve customer issues actively working in the surviving org. 

Prodly DevOps can help seed your sandbox, as well as automate the entire work migration process quickly and compliantly during an org merge. Check out our FREE on-demand webinar, Easier Org Merges, to see how we can help you prepare and perform your next org merge. 

FAQs

What is a Salesforce org?

A Salesforce org is a dedicated instance of the Salesforce platform where you store and manage your organization’s data, configurations, and customizations. Each org has its own set of users, data, and security settings and can be customized with various apps, objects, fields, workflows, and integrations.

 

How does a Salesforce org merge reduce technical debt?

When you consolidate two or more Salesforce orgs, you can significantly reduce technical debt by consolidating data, reducing the number of customized components you need to maintain, and minimizing the number of apps and integrations you need for your surviving org to function optimally. Learn more about technical debt in Salesforce.

A digital bull's eye representing data accuracy

Salesforce Record IDs: When Do They Change?

Deploying relational data between Salesforce orgs can be challenging when you’re navigating how and when Salesforce record IDs change. If you’re not careful, you may end up with duplicate records… and a lot of extra work.

In this blog, we discuss when record IDs are different and when they remain the same. We also explain how to prevent duplicate data records with Prodly.

Salesforce Record IDs Are Different After Data Migration

Salesforce assigns a unique record ID to each record when you import it into an org. It doesn’t matter whether you import it using manual entry, a simple single-object data loader, or a sophisticated data migration tool like Prodly. 

Salesforce breaks the association between orgs. When you move a data set from one org to another, Salesforce assigns a new record ID to each record in the data set. Think, for example, of when you move data from sandbox to production or from production to sandbox.

Salesforce Record IDs Remain the Same After a Refresh

During a full or partial sandbox refresh, Salesforce copies Salesforce record IDs from production to the sandbox. Because it copies the record IDs, they remain the same. 

Salesforce also copies record IDs when you refresh a Developer or Developer Pro sandbox for standard objects like Products, Price Books, Price Book Entries. It also copies them when you clone a sandbox.

Even when it copies record IDs, Salesforce still breaks the association of the records between orgs. Because the orgs aren’t synced, changes in one org after the refresh will not be reflected in the other.

When you move updated data from a sandbox to your production org, Salesforce assigns a new record ID to each record. If you haven’t taken any precautions against duplication, Salesforce inserts the data set from the sandbox without updating any of the old records in production.

How to Solve the Duplicate Data Problem Manually

Many Salesforce admins get frustrated with the process of deploying data between orgs without creating duplicate records.

Oftentimes, they assign external IDs to each object in a data set to associate the object with a parent object outside Salesforce. If you’ve used this technique before, you know it’s laborious, time consuming, and prone to error.

Prodly Prevents Duplicate Data With Automation

Prodly eliminates this time-consuming manual task with its exclusive automatch feature. When you migrate data, the automatch manager automatically creates an association between source and destination org Salesforce record IDs. It then stores this information in the Prodly app. 

This eliminates the need to manually create and maintain formal external IDs on every record. And that saves you a lot of time and work.

A digital bull's eye representing data accuracy

When you deploy data between orgs, Prodly first checks to see if the source records have a matching record with the same Salesforce record ID in the destination org.

If there isn’t a match, Prodly checks its automatch database to see if the records are the same but the IDs are different. If Prodly doesn’t find a match, it creates a new record. This prevents duplicates during a data deployment.

It’s best to set up the automatch manager when you move data from an existing org to an empty one, from a sandbox to a production org, or after a sandbox refresh.

However, you can still set up automatch during a development cycle. This involves a few extra steps to consolidate data and ensure the automatch manager accounts for all the matching records.

Learn more about setting up the automatch manager and about automatch in general on our help site.

Successful relational data deployment starts with understanding when Salesforce record IDs change and when they’re copied.

Prodly takes matching and changing Salesforce record IDs into account when you deploy relational data with the automatch manager. This solves the problem of duplicate data records without extensive use of external IDs.

Simplify Salesforce data migration

Simplifying Salesforce CPQ Implementations for Coastal Cloud

Coastal Cloud leverages Prodly to facilitate faster, more accurate Salesforce CPQ implementations.

Salesforce CPQ Implementations Are Smoother With Prodly

Coastal Cloud is a Salesforce™ Platinum Partner based in Florida, with additional development centers in Kentucky and Colorado. They help clients leverage Salesforce Revenue Cloud (Salesforce CPQ and Billing) to improve business results and deliver a superior customer experience.

Q2C implementations can be a time-consuming process due to the complexities of relational data migration. Coastal Cloud has overcome this challenge by employing Prodly.

This Q&A with Mike Ackerman of Coastal Cloud discusses how his team uses Prodly to enable efficient Salesforce CPQ implementations.

Simplify Salesforce data migration

Q: Mike, what is your role at Coastal Cloud?

I’m a senior technical architect at Coastal Cloud. I help our client implementation teams during the design, build, and deployment phases. I promote best practices and best-in-class tools so our consulting teams can deliver projects consistently and efficiently.

Q: Can you describe Coastal Cloud’s experience with Salesforce CPQ and Billing implementations?

We’re a leading implementation partner of Salesforce Revenue Cloud, which includes Salesforce CPQ and Salesforce Billing. We’ve implemented some of the largest and most complex quote-to-cash deployments to date.

Coastal Cloud is on a shortlist of partners with deep experience in both CPQ and Billing. We’re a long-standing partner. We worked with SteelBrick, which was founded by Prodly’s CEO, before it was acquired by Salesforce and became Salesforce CPQ. We’re happy to say that relationship continues today.

We’ve performed many Salesforce CPQ and Billing deployments with complex configurations of products, pricing, availability, discounting, billing, and revenue recognition rules.

Our quote-to-cash projects range in complexity. We’ve completed simple Salesforce CPQ implementations for midsize companies and highly complex implementations for large enterprises. With quote-to-cash playing a central business role, we often integrate with ERP and other systems.

Q: Why is quote-to-cash, and CPQ in particular, so challenging from a relational data migration perspective?

The real power of Salesforce CPQ is the flexibility and configurability. You need the ability to make product catalog reference data changes quickly and easily to leverage that power.

However, there’s a complex reference model working behind the scenes to enable this configurability in Salesforce CPQ. Implementation teams need to treat this reference data as another important artifact to be appropriately managed across environments.

When it comes to disciplined configuration management, you need to treat reference data as a first-class citizen. This is alongside the programmatic and declarative deliverables necessary to build and deliver the project.

Q: Why is relational data migration such a challenge?

Before we discovered Prodly, our teams executed a very labor-intensive process. It involved exporting configuration data changes to spreadsheets and meticulously loading them back into the target environments.

Salesforce’s internal IDs and lookup relationships are very complicated. So that load process had to account for the re-keying of relationship data. We needed to carefully load the parent and child rows in the correct order. Then we have to re-key the child rows to point to the newly imported parent.

This is a concern with related objects, as well as with rows within the same object that have a recursive relationship. You need to ensure that you’re loading the rows within the same object in the right order. Plus, you need to re-key those child rows before you can load them.

When you deliver changes to an existing target of reference objects, you identify each row with a unique external key. That way, you know if a row is being updated, inserted or deleted.

As you can imagine, using export spreadsheets with Data Loader can be a very labor-intensive and error-prone process.

After we discovered Prodly, this became a much more automated process. It saves us significant effort and reduces the risk of error.

Q: How long did it take to migrate reference data without Prodly?

Many factors impact the complexity of the Salesforce CPQ and Salesforce Billing model. Think of how many products are in the catalog, as well as the number of options and features you have. In addition, consider the complexity of the pricing and discounting rules.

All these factors influence the migration effort. However, it can easily take a full day to do one load without effective tools. This isn’t a scalable process when you’re following an agile development model.

Q: How do you integrate Prodly into your Salesforce CPQ implementation process?

In an agile development environment with two-week sprints, you want to set up and shut down feature development environments frequently.

To make your developers productive, provide them a full copy of the product catalog from which to develop and test. And you need to reduce that full-day migration process to execute refreshes reliably and frequently.

Let’s say we have three developers working on a two-week sprint. We start the sprint by setting up three empty DevPro orgs . Then we use Prodly to instantly populate these empty orgs with current product catalog reference data. Later, we’ll migrate that reference data to a fourth environment to support testing activities.

We also use Prodly for quick, ongoing deliveries of incremental data changes for bug fixes. When a fix is ready for production, we save time and reduce risk by delivering the final reference data using Prodly.

Note that we reduce our users’ outage window significantly by using Prodly during the production migration.

Q: How do you avoid duplicates when you migrate relational data?

You’ve got to ensure you have a unique surrogate identifying key on each of the rows of the product reference objects.

Prodly uses this key to identify whether it’s an insert, update, or delete action when copying the data. Hopefully, a surrogate key exists in your data set already, but a lot of times we find one does not.

For instance, you might assume the product SKU is surrogate, but in reality there may be business meaning in that SKU. Perhaps those first two letters of the SKU indicate the line of business.

Perhaps the business team decides somewhere down the line that they want to change that SKU during a rebranding effort. Where you thought something was a surrogate unique identifier, it may in fact change in the future. That could break your deployment process.

Ideally, you want to start the project by identifying truly unique surrogate IDs for each row. You want the developers to set a surrogate ID once—and know it is never going to change.

IDs should have no business meaning and must reliably identify the uniqueness of a row as it moves across environments.

As Salesforce developers know, we can’t use the Salesforce ID for a surrogate key. The ID is not updatable and it changes as it moves from org to org. Surrogate IDs are an important success factor in making the reference data management process reliable.

Q: How exactly do you configure Prodly data sets to migrate CPQ reference data?

Today, this is part of the startup steps for getting a Salesforce CPQ implementation project up and running. We install Prodly in the client’s org. Then we the data set or template for the objects we’re going to ask Prodly to move back and forth.

The data set represents the configuration, or instructions, on how the data will be moved. We define this initially in production to prepare for the copy of data from production to our development and test orgs.

When you’ve made changes in the development org, it becomes the new source. Those changes can be copied to test and later to production. To re-use the data set configuration we already defined in production, we copy it to the development org. That way, it can also facilitate that org’s new role as being the source for changes.

Currently, Prodly must be installed in any org that acts as a source for copying data. We can also use Prodly to push its own data set configurations to and from various source orgs. That way, we don’t need to re-define the data set from scratch. We’re essentially creating our own template.

With Prodly’s centralized deployment architecture, pushing data sets and installing Prodly in the various source orgs will no longer be necessary. Instead, we’ll be able to manage deployments from a central org. This will be another big time saver.

The centralized deployment console can potentially offer smaller clients a shared reference data management service based on Prodly.

Q: How do you hand off the reference data update process to a client once you finish your Salesforce CPQ implementation?

Our standard methods and tools now include the use of Prodly for managing complex reference data migrations.

During our discovery phase, we identify if these challenges are present. Our teams identify this risk early and ensure the project is scoped to include the appropriate tools to mitigate this risk. This helps to ensure our clients and delivery teams are set up for success.

Prodly is a key part of our risk mitigation tool set.

Ideally, we want our clients to procure their own Prodly licenses. That way, once we’ve successfully delivered our project, the client’s Salesforce support team can continue to smoothly execute the process.

We ensure the process is well documented and train the client’s administrators on how to use the tools. We have a very robust configuration and release management process that’s well documented and repeatable.

Some clients opt to engage us for long-term Salesforce support. In those cases, which we continue to leverage Prodly for highly efficient reference data management.

Q: Any final thoughts?

Using Prodly, we’ve been able to dramatically improve the efficiency and quality of managing our Salesforce quote-to-cash data. We’ve taken a day-long reference data process and now execute it reliably in mere minutes. Prodly has drastically improved the way we operate and increased the ROI for our Salesforce quote-to-cash clients.

Do these Salesforce CPQ data migration challenges sound familiar to you? 

Schedule a free demo now to see how Prodly can help !