Salesforce production orgs are complex and hold lots of information, so making the decision to move it all to another production org is a serious undertaking for even the most seasoned developers. But for some businesses there are cases where merging two Salesforce production orgs is simply unavoidable.
Given the complexity involved, org merge projects need to be planned carefully. In this post we look at the major considerations companies need to think about before merging Salesforce orgs together.
Why would I merge my Salesforce orgs?
A senior stakeholder might decide to merge orgs for a number of reasons, but there are some common use cases where merging Salesforce orgs seems necessary:
Mergers and acquisitions: A big merger or acquisition often means that two companies need to consolidate their processes into one Salesforce org. This can be particularly tricky when stakeholders across both companies want a say in how the new processes will work.
Cost savings: Production orgs are very expensive, even before factoring in the cost of maintaining them. If your company has a few different business units, each with their own production org, then merging some together can be an effective way to find cost savings under budgetary pressure. Merging the orgs will mean paying less in licensing fees for doubled-up applications and integrations.
Creating a single source of truth: Merging two Salesforce orgs can unify the data you hold into one single source of truth. This improves visibility across the company and standardizes processes, building better customer relationships.
Reduce maintenance: Production orgs aren’t easy to maintain. The complexity of metadata customizations, the volume of data, plus security and compliance considerations all require careful attention. Merging orgs avoids duplication of maintenance work.
Reduce technical debt: Cleaning up the existing data and metadata in both your orgs is a big part of reducing the technical debt that has built up over time. Whether you choose an existing org to become your “master org”, or start an entirely new one from scratch to populate, only choosing the data and metadata that you really need will eliminate redundant items that have been building up over time.
Live eventSan Francisco CA
Dreamforce
Reasons to keep your production orgs separate
While merging two orgs has many benefits, there are some reasons why it makes more business sense to keep them completely separate:
Time and cost: Assessing the ROI on an org merge project is pretty much the first thing that should happen to make sure you aren’t wasting time on a project that’s not financially viable. Teams should be convinced that the costs saved by undertaking an org merge outweigh the cost spent on the migration.
Complex merging process: After considering the merge, it might be decided that it’s too complex a job to carry out. The risk of downtime or disrupting daily operations could outweigh the benefits, especially with large companies and after careful consideration. A company could also decide that an org merge project isn’t as valuable as another digital transformation project they want to complete.
Distinct business divide: After a merger or acquisition, it isn’t necessarily best to merge orgs. If products and services aren’t being closely combined, it may be simpler to keep each org running independently.
Compliance complications: If the data in different orgs are subject to different compliance frameworks or data protection laws, it may vastly overcomplicate compliance to attempt an org merge.
Performance: Keeping two orgs separate can help speed up performance. The closer the org creeps towards the storage limit or governor limit, the slower processes may run across the board. Smaller data sets are quicker to process, which leads to everything from queries, reports and dashboards being retrieved much faster.
Different release pipelines: Are you going to be able to sustain a pipeline of work after your Salesforce org consolidation? What volume of changes will be coming through? Will they need to be handled using a different development model to the ones used when the orgs were separate? These are all considerations that need to be taken into account to maintain the performance of your orgs.
Best practices for merging your orgs together
When faced with complex merges, attempting to deploy all differences in one go will almost certainly result in an overwhelming number of validation failures from Salesforce.
No business should attempt to merge their orgs together without careful consideration and planning. To help with the planning process, we’ve put together these best practices for the key stages of merging orgs: preparation, business continuity and maintenance.
Every company is different and there’s a number of ways that an org merge can be carried out. Because of this, it’s not possible to give a definitive list of steps. These best practices are considerations, and may not be the only things that your team need to consider.
Before: Prepare every step of the merge
Sharing rules, third-party integrations and any associated middleware, backups for restore, field number limits on objects, metadata types, and any customizations should all be carefully considered before anything is moved from one org to another.
Identify the merge team
Putting together a team responsible for the entire merge project will help stakeholders know who to contact, and stop mixed messages about the merge being shared across the company. In a merger or acquisition, it’s highly recommended to include members from each business. This will give a fair representation across both businesses and make sure that everything needed from the existing orgs is taken across.
Understand your business processes
Before evening thinking about combining your orgs, take the time to understand your business processes for each org. Of course they won’t be identical, so your merge team needs to identify the common processes, and what these will look like in the combined org.
Audit your orgs
Take an audit of the orgs and assess the risks associated with any inbound or outbound integrations that you might be introducing into the new org. Severing a tie that you didn’t know existed could leave an integration trying to talk to a non-existent org. If creating a new org, make sure it has all the correct features and add-ons enabled. Otherwise you’ll hit blockers with metadata or data migration down the line. It’s also worth identifying any contacts that require extra compliance measures with GDPR, HIPAA, etc.
Compare metadata
Perform metadata comparisons between your existing and new org (if relevant) to understand the differences and decide what needs to be taken across as part of the merge.
Don’t forget your applications
Take stock of what apps or integrations you have in each org. There may be some that are no longer needed and can be decluttered. Others will need to be implemented in the new or combined org. And don’t forget anything that’s dependent on your old orgs to keep running, which you might inadvertently break as a result of the merge.
Identify business-critical data to migrate first
Data migration is a mammoth task, especially if the orgs have lived for a long time. Differentiating the data that is most useful or business-critical for migration is one of most important tasks. Batching the data will make your deployments less likely to fail. You can also hit issues due to records being locked and CPU timeouts the risk of record locking when doing parallel batch uploads if the data hasn’t been sorted correctly.
Clean up your data
Migrating data that you don’t need not only wastes time in the migration process, but it also takes up valuable storage space in the new org. Migrating data is the perfect opportunity to sit down and work out what you can do without. If you need to keep data for compliance reasons, but don’t need those records in your orgs, you should archive that data.
If one org’s data has been inputted in a different format to the other, then using an ETL tool can help correct the data as it moves across. For example, Org A might have dates written MM/DD/YY, while Org B has dates written YYYY-MM-DD. An ETL tool will extract and clean the data from Org A and transform it so that it will merge perfectly into Org B.
Implement a backup and recovery solution
Make sure you have a backup solution in place before you start moving data and metadata around from org to org. Having this safety blanket firmly in place before you start means you can carefully track the merge and revert anything quickly if you spot a problem, like a load of missing data.
During: Communication is key
Communicate the process
Keeping the key stakeholders up-to-date on the details of the merge and communicating the merge process to the wider business will keep everyone informed and feeling involved. This will also help anyone dependent on Salesforce to prepare for the downtime and put plans in place should the orgs not be up and running as quickly as expected. Using a ticketing system like Jira will allow stakeholders to keep track of the deployments as they take place during the merge.
Planned downtime
It’s inevitable that some downtime will happen when carrying out the process of merging. Setting aside a defined amount of time, preferably at a quieter time in the working week, will mean the impact on your end users is minimal. It also means that if something doesn’t quite go to plan, you can fix it in a calmer environment, without frustrating your end users.
User management
Identifying any user overlaps between the orgs and making sure the correct permissions and roles are assigned to the right teams is crucial for making the org merge as secure as possible. Properly configured permissions prevent unauthorized access, reducing the risk of sensitive data falling into the wrong hands. If the merge is because of an acquisition and the permissions are completely different between the two orgs, then they will need to be consolidated and there might need to be a change to the way of working.
Regression testing
It’s important to carry out rigorous regression testing — using comprehensive automated test suites — to make sure that nothing is going to break unexpectedly once the merge is underway. It’s worthwhile running these tests at multiple stages of the merge process, including after major milestones like data migration, custom code integration, and before going live.
After: Test rigourously and maintain your org
Post-merge testing
Perform thorough post-merge testing to ensure all systems and processes are functioning as expected. Being this close to the finish line can mean testing is rushed, but it’s important to be as thorough as possible before letting your end users back into the orgs.
Post-merge support for users
Supporting end users as much as possible after the merge will help smooth the transition to the unified org that’s now your new source of truth. Training on the new environment and its workflows, features and processes will be necessary to bring end users up to speed.
Continuous monitoring and maintenance
Monitoring the platform performance, ongoing checks and data cleaning will become standard maintenance activities following the org merge. Audits and other compliance checks will be necessary at certain times as well as needing to implement backups, including a disaster recovery plan, for the new org too.
With a big project like the merging of two production orgs, you will be making iterative improvements all the time, addressing new pain points and improving processes constantly.
Retiring the old org
Once you’re sure that you’ve successfully merged your orgs, you can start creating a plan for retiring the redundant org. Freeze the org while any final checks are made on the new org and, once everything is confirmed, you can carry out the final deactivation. Record the entire retirement process, including what was done with the data, who approved each step, and any challenges faced in case this is needed for compliance regulators down the line.
How can Gearset help?
When you’re ready to merge the two production orgs together, it’s really important to start with the metadata before you try and move any data. You can’t move the data if it has nowhere to go.
With Gearset you can compare the metadata across both your production orgs to see what’s missing and what you want to take across from the legacy org you’re retiring, to the live org that you will continue with — whether that’s a brand new org, or one that exists already.
When it comes to moving the metadata, it’s best to split your deployment into these 5 stages. Each stage will move a subset of metadata in an order that builds the org from the bottom up.
Data tier: First, migrate the core components that set the data structure of the org, and on top of which most other customizations are built. This will include Custom Objects, Custom Fields, Custom Apps, Value Sets, Static Resources, Content Assets and Picklists.
Programmability: Next, add the custom code you’ve built. This is your Apex: Classes, Components, Tests, and Triggers.
Presentation: With the code in place, you can begin updating your modifications to how your end users interact with the platform, such as Lightning Pages and Components, and Layouts.
Permissions and security model: Add in the security model to ensure everyone has the correct access. This includes Field-Level Security, Profiles, Permission Sets, Security Settings, Roles, and Sharing Rules.
Other: Finally, migrate any other components or types required. This list will vary, but may include Email Templates, Reports, Static Resources, Flows, Workflows and Documents.
In Gearset, you can click on any item in the comparison results to see what it depends on, and whether any other items depend on it. This helps you map out the core dependencies as you begin to plan the deployment steps. Gearset’s problem analyzers will pick up any missing dependencies while working through these incremental deployments.
Once you have the metadata in place, Gearset’s data deployment solution allows you to deploy records to multiple Salesforce objects in a single run while keeping all the data relationships. Gearset is well suited to the task of merging orgs because you’re able to migrate records directly between orgs. If you were using something like Salesforce’s Data Loader, you would be working outside your orgs, on CSV files — which adds another opportunity to introduce errors. Gearset also prevents duplicate records, which is especially useful when merging two orgs that could have overlapping information.
You can save templates to be used again and control batch sizes so you can keep full control of what’s moving when.
Merge your orgs with confidence
Planning the merge meticulously and communicating to all stakeholders is key to making sure that the merge is completed as smoothly as possible.
If you’re planning to merge multiple orgs, start your free 30-day trial of Gearset to see how we can help compare your metadata across the orgs and also deploy your metadata and data to the new org, when you’re ready. You can also book a consultation with one of our experts to see how Gearset can help you with a merge you’re planning to make.
If you want to continue reading, download our ebook Salesforce DevOps at Enterprise Scale.
