Why Choose a 'Lift and Shift' Org Merge?
A Salesforce org merge is the process of combining two or more Salesforce organizations into a single instance to consolidate data, streamline processes, reduce costs, and improve reporting. It typically occurs due to mergers, acquisitions, or operational unification needs.
A lift and shift org merge involves migrating one Salesforce org into another with minimal changes, essentially moving data and customizations as-is. It is considered when speed and simplicity are priorities, typically in scenarios like acquisitions or quick consolidation, with limited focus on optimization or restructuring.
When to Consider a 'Lift and Shift' Org Merge
A "lift and shift" Org merge is common when Salesforce Orgs are merged as a result of company acquisition. However, you should consider this approach in the following scenarios:
Time is of the essence: there are business and financial factors, like limited budget, that necessitate the merge to be completed quickly, without big business transformation.
Limited Resources: Resources are constrained, making extensive process redesign impractical.
Operational Continuity: The primary goal is to keep business operations uninterrupted.
Low Appetite for Change: Stakeholders prefer to avoid the complexity, cost, or time required for a full process redesign.
Prerequisites
In order to follow this guide you need:
Salesforce Metadata Management license
2 Salesforce Orgs (to be merged together) synced into Metadata Dictionary
Both of these Orgs need to be Production Orgs or at the very least Full Sandbox Orgs (because data population analysis is a big part of this methodology)
This solution guide covers use-case for using MetaFields functionality. You can learn more about setting it up here.
Define your MetaFields
When doing an Org Merge, one Org (source) is being deprecated, and another is being used as the 'target'. And we need to migrate data from the source Org into the target Org. That often requires we also move across some metadata configuration to preserve data accuracy and business operations.
While you need both Orgs synced to perform comparison analysis, the MetaFields provided below should only be created for the Org being deprecated.
Create following 6 MetaFields with Org Merge project in-mind for the Org that will be
deprecated during the Org Merge:
MetaFields definitions
MetaFields definitions
Business importance (picklist):
Values:
Core: Critical to key business operations and must be migrated.
Secondary: Supports business operations but is not critical; useful but not essential.
Not Important: Has no records or is otherwise deemed non-essential; should be left behind.
Purpose: Classify components based on their importance to business continuity, guiding decisions on what must be migrated and what can be omitted.
Retention priority (picklist):
Values:
Must Retain: Essential for the merged Org; migration is mandatory.
Optional: Nice to have but not critical; can be migrated if it doesn’t cause issues.
Not needed: Not relevant for the merge, typically applied to components with no records or that are redundant.
Purpose: Prioritize components for retention or elimination, focusing on the components that are most valuable to the merged Org.
Condition: Make this picklist conditional on Business importance being Core or Secondary. Objects that are deemed not important, don't need to be considered for the merge at all.
Merge plan (picklist):
Values:
Merge: Move data from source object to target object
Recreate: Source object has no equivalent in the target Org and it will have to be re-built in the target Org before data can be migrated.
Archive on platform: Data from the source object is of interest to the target Org for historical reporting and should be migrated to the target Org into a new object (for instance a Big object).
Archive off platform: Data from the source object is of interest to the target Org but no active reporting or actions are expected. Data can be stored off platform, in a spreadsheet or other source.
Purpose: Document what is the expected business outcome, i.e. how the data should be 'merged' into the target Org.
Condition: Make this picklist conditional on Retention priority having values Must Retain or Optional. If object's data is not needed for the merge, no merge plan is necessary.
Customization level (picklist):
Values:
Standard: Out-of-the-box Salesforce component.
Custom: Modified or custom-built for the Org.
Highly Customized: Extensively customized and may impact other components.
Purpose: Determine the level of customization for each component, helping assess the effort required to merge and whether the component can be easily integrated into the target Org.
Impact level (picklist):
Values:
Low: Few dependencies, can be merged with minimal impact.
Medium: Moderate dependencies, requires some review to ensure smooth integration.
High: Extensive dependencies, needs thorough analysis and possibly custom migration plans.
Purpose: Evaluate the impact of merging a component based on its dependencies on other components, ensuring that dependent systems and processes are not disrupted.
Conflict potential (picklist):
Values:
Low: Minimal risk of conflict, likely to merge smoothly.
Medium: Some risk of conflict, requires careful review.
High: High risk of conflict, needs detailed evaluation and possibly custom solutions.
No conflict: the object being merged is unique and there is no conflict at all with schema and configuration in the target Org.
Purpose: Assess the likelihood of conflicts between components in the Org being merged and the target Org. This helps prioritize conflict resolution and planning.
Impact level field is useful for non-field metadata types. Elements automatically scores impact level for fields in your Org. Read more here.
Scope your 'lift and shift' Org Merge project
Here are proposed steps for analyzing both Orgs to be merged and scoping the effort and preparing the plan for the merger.
Per our prerequisites, we assume you have 2 Salesforce Production / Full Sandbox Orgs (to be merged together) already synced into two separate Metadata Dictionaries.
Step 1: Identify objects to be left out from the merge
Start by creating a custom view of metadata in the Metadata dictionary for the Org that will be deprecated during the merge. The custom view should include all the standard and custom objects in your Org. Ensure you select following attributes:
API name
Name
Description
Record count
Last created record date
Last modified record date
The defined MetaFields.
Then apply sorting alphabetically by name.
Tip: the reason to start by analyzing objects is the Org that will be deprecated is that essentially you want to migrate data stored in this Org to the target Org.
You need to understand which objects even hold any data of value in order to properly scope which automations, fields and other metadata you will be analyzing (after all, there is no point re-building objects that are not used in the source Org!)
Current limitation: currently you cannot filter a custom view of metadata by greater than / less than number of record counts. Scan the list visually to quickly find any objects with 0 records.
You can also export the list of objects as a CSV file and filter it in a spreadsheet.
You can do bulk-update MetaFields using bulk-actions within your custom view of metadata. Any objects with 0 records should be classified as:
Business importance: Not important
Retention priority: Not needed
Any objects that hold any data should be left for further analysis with stakeholders.
Step 2: Review the remaining objects with stakeholders from both Orgs
Tip: It is important to gather together key decision makers from both Salesforce Orgs for the review of the objects. This is because:
Platform owner, or department heads, for the 'source' Org should know which objects are still being used by the business and why
Platform owner, or other executive, for the 'target' Org should know which parts of the other Org's operations and data they are even interested in migrating
You can also rely on more granular list of stakeholders if you have previously documented business stakeholders on objects in both Orgs.
Apply filter to the previously created custom view of all standard and custom objects to exclude any objects with business importance: not important. Then review remaining objects for their Business importance and Retention priority with business stakeholders.
For any object that ends up being classified as Core or Secondary in terms of business importance, and is considered for retention, document what is the expected merge outcome. Using Merge Plan picklist, classify the objects as one of the following:
Merge: Move data from source object to target object
Recreate: Source object has no equivalent in the target Org and it will have to be re-built in the target Org before data can be migrated.
Archive on platform: Data from the source object is of interest to the target Org for historical reporting and should be migrated to the target Org into a new object (for instance a Big object).
Archive off platform: Data from the source object is of interest to the target Org but no active reporting or actions are expected. Data can be stored off platform, in a spreadsheet or other source.
Reminder: You can do bulk-update MetaFields using bulk-actions within your custom view of metadata.
Step 3: Prioritize objects for analysis
As a result of the review with the key stakeholders, you will end up with a list of the objects in the source Org that are:
Important (Business importance marked as Core or Secondary)
Should be retained after the merge (Retention priority marked as Must Retain or Optional)
And should be moved to the target Salesforce Org (Merge plan marked as either Merge, Recreate or Archive on platform)
However, this is just the initial 'business wishlist'. The true cost and complexity of the Merge is not yet understood and the results may impact the merge strategy.
Use the matrix below to prioritize which objects, and adjacent metadata, should be analyzed in what order. Adjust the filters in your custom view of metadata of objects to only include those that match component importance and retention priority values as specified below.
Business Importance | Retention Priority | Merge Plan | Priority Level |
Core | Must Retain | Merge, Re-create or Archive on platform | 1 |
Core | Optional | Merge, Re-create or Archive on platform | 2 |
Secondary | Must retain | Merge, Re-create or Archive on platform | 3 |
Secondary | Optional | Merge, Re-create or Archive on platform | 4 |
Step 4: Review and assess objects marked for retention
At this point you have a custom view of Source Org's objects that has filters defined to only shows those that have a specified business importance and retention priority based on matrix above.
Now go object-by-object in your list and assess:
Level of customization
Objects can be very lean, with a handful if any custom fields, or extremely bloated, with hundreds of record types, custom fields, different page layouts, validation rules, and other features.
Click on the object in your list, then open the 'Details' tab in the right panel and scroll down to see the breakdown of metadata types present on the object.
Based on the findings, classify the object in the Assessment tab as 'Customization' "Standard", "Custom", or "Highly customized".
Click apply to save the classification.
Tip: 'Standard' value is really reserved for Standard objects. You can use that to gauge whether Account, Case, Opportunity, Contact and others have been pretty much used with their 'out-of-the-box' configuration or changed.
Impact
Objects can be highly customized or extremely lean. But that is only one dimension of whether an Object will be easy or hard to transition into another Org. The other dimension is what sort of automations and processes the Object relies on.
For instance, just migrating all the contacts from source Org to target Org is not enough, if there are automations (apex, flows) that automatically create those contacts from web forms, product registrations and other sources.
In you list, click on the object being analyzed. Open the 'Dependency / usage' tab in the right panel. You will see the list of automations and report types where the object is referenced. You can open up each section to see and inspect individual components.
Based on the findings, classify the object in the Assessment tab as 'Impact level' "Low", "Medium", or "High".
Click apply to save the classification.
Step 5: Identify any adjacent objects that may need to be migrated
The 'data' that the business wishes to migrate from the source Org into the target Org is not merely stored in one object. Take contacts, for instance. Contacts belong to accounts, they can be featured on cases, tasks, and plenty of other standard and custom objects. Therefore 'retaining' contact data may indeed require doing a massive migration from across dozens of objects.
However, just because the source Org data model supports a specific object relationship, it doesn't mean that it has been used by the business. And if that is the case, then it doesn't need to be in scope of the merge.
In order to identify any adjacent objects that may need to be included in the merge for data completeness, or to re-evaluate if object already added to merge scope may not be needed, follow these steps:
For selected objects, open the dependency tab in the right panel.
Open the list of 'Fields' using that object - these will be lookup / master-detail fields pointing at the selected objects.
Click on the listed fields and open them in the new tab.
Review the population insight.
Any field that hasn't been populated (0 records) signifies that this particular object relationship hasn't been used, and therefore it is not needed for the merge to retain data completeness.
Any field that has some population signifies that there is some data stored on is parent object that may be relevant to the core object we wish to keep.
Make sure that the parent object of the lookup field that shows utilization to the object we want to keep is properly assessed in terms of business importance and retention priority.
Tip: listed lookup fields already come highlighted with automatically calculated Impact score. Any field that has been populated more than 2% of the time will never be classified as 'Low' impact.
Step 6: Compare objects between Orgs
At this point, in your custom view of metadata, you have a list of objects in your source Org that:
Have been pre-filtered to only show those that have a specified business importance and retention priority (e.g. Core and Must Retain).
Have been classified by Customizaton and Impact levels
The next step is to classify the source objects by what type of conflict / effort we can expect when trying to merge it into the target Org. To do that:
Open the Metadata Dictionary for the 'Target' Org
Just like in our Source Org, create a custom view of metadata with all the standard and custom objects in that Org. Ensure you select following attributes:
API name
Name
Description
Try to find an Object in the Target Org Metadata Dictionary that has been classified and is present in your view in the Source Org Metadata Dictionary
Tip: Comparing standard objects is easy because they need to have the same names across all Orgs. But comparing custom objects is more difficult because they may exist in two different Orgs under different names. Or worse still, there are objects which are named differently, and overlap in purpose, but are not exactly the same.
Here are things you may try:
Search objects in the target Org by name as well as name synonyms (if there is a 'bug' custom object in the Source Org, try looking for 'Problem', 'Issue', 'Dev', 'Ticket', 'Resolution' or adjacent phrases)
Review the descriptions for objects to infer their meaning
Sit down with Platform Owner for the Target Org and review specified objects in the Source Org with their stated purpose to identify which objects in the Target Org may serve similar purpose.
Classify conflict
If object does not exist in the target Org, only in the source Org, then by definition conflict level can be set as 'No conflict'. Since by re-creating the object configuration, adjacent automations, and importing the data into the target Org we are not risking any existing data.
When an object has been identified in the target Org as serving the same or similar purpose as in the source Org, use the matrix below to decide how to classify the conflict level:
Customization | Impact level | Conflict level |
Highly customized | High | High |
Highly customized | Medium | High |
Highly customized | Low | High |
Customized | High | High |
Customized | Medium | Medium |
Customized | Low | Medium |
Standard | High | High |
Standard | Medium | Medium |
Standard | Low | Low |
Based on the findings, classify the object in the Assessment tab as 'Conflict level' "Low", "Medium", "High", or "No conflict".
Click apply to save the classification.
Step 7: Repeat
At this point, you have completed analysis of one of the segments of your objects. Update your custom view of objects to reflect the new segment. For instance, if you analyzed objects classified as Importance: Core and Retention Priority: Must Retain, then move on to the next segment in the order of priority.
Now repeat the analysis steps #4, #5 and #6 for the new segment of objects.
Repeat the cycle of each object segment until you are done.
Plan merge execution
After the scoping of your Org Merge project is finished, you will end up with a list of objects from the Source Org classified by their importance, retention priority, customization, impact, and conflict levels. What to do with that information?
Step 1: Prepare merge strategy
Below is the proposed decision matrix of how to interpret the classification and drive prioritization decisions.
Of all the classifications, focus on 'Retention priority' and 'Conflict' values for your objects. This is because both of them are derived and conditional on classification in prior MetaFields.
Retention Priority | Conflict Level | Priority Segment | Why? |
Must Retain | Low | 1 | These objects are core to the business and must be retained, but they are simpler to migrate. Starting with these allows you to achieve quick wins and build up momentum for the more complex migrations. |
Must Retain | Medium | 2 | Prioritize after quick wins have been achieved. |
Must Retain | High | 3 | This is arguably the most difficult part of the Org merge project. These are objects which are critical to the business but require a lot of effort to migrate. |
Optional | High | 4 | Review carefully with stakeholders from both Orgs, consider conflicts before deciding on retention. |
Optional | Medium | 5 | Prioritize after must-retain components, resolve conflicts if needed. |
Optional | Low | 6 | Address after more critical and conflict-heavy components. |
Step 2: Document merge action items
Custom views of metadata come equipped with many single and bulk operations. You can raise user stories and document tasks to merge metadata into the target Org.
You can specify importance, priority, data migration plans, and other critical merge actions in-bulk for objects that fall under the same segment.
You can then pick up those stories from your backlog and deliver then when there is capacity.
