VP of Marketing
Hayley Coxon is the Vice President of Marketing and Revenue Operations for Prodly and accidental admin since 2010. You can find her on LinkedIn.
An org merge is the process of combining one or more production instances of Salesforce. On the surface it sounds simple, but in reality an org merge means deciding how to merge two orgs with different processes, objects, fields, data, access levels, and the list goes on. An org merge also tends to be a period of deep reflection and reevaluation of how Salesforce will support the business’ growth going forward. Typically, one of the orgs is selected as the surviving—or master—org, but org merges can also combine multiple orgs into a new Salesforce org. Either way, parts of the legacy org may survive the merge. Perhaps the legacy org had a better solution for a shared business process or solved an issue that the master org never encountered. At a minimum, you’ll need to merge any data you want to keep from the legacy org into the surviving org.
So if it’s such a large effort, why would anyone in their right mind consider merging Salesforce orgs? The most common reason is a corporate acquisition where one company purchases another, and both companies use Salesforce as their CRM. In order to fully integrate the two companies, you need to integrate their systems. Following the integration period, there can only be one source of truth. After all to effectively market, sell, and service customers and prospects, employees must be able to first identify who is a customer or prospect.
Another common reason for merging Salesforce orgs is to reduce accumulated technical debt. Decisions, processes, and workarounds that made sense even a few years ago, may no longer make sense. While there may have originally been valid reasons for separate business units to operate in their Salesforce orgs, today it could be inhibiting greater collaboration or no longer be a cost effective option. In more extreme cases, 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.
Each org merge project is unique and will have different criteria for success, but the process for completing a merge is largely the same.
The first step is to get a plan in place, starting with a loose timeline for the merge. (Are their hard deadlines, like expiring licenses that will drive milestones?) Next, build your org merge team. This is not a one person job. It’s critical to engage your stakeholders early, and every team potentially impacted by the merge should be represented. On the technical side you’re going to need someone who understands the data structure of both orgs and can make recommendations on the best way to map data from the legacy org into the surviving org. If you have one, a Salesforce Center of Excellence is an excellent starting point to recruit your org merge team.
Then, assess the systems that will be impacted. This will include, your core Salesforce Clouds, as well as:
Once you have a list of everyone and everything that could be impacted by the org merge, you’re ready to document requirements. Is all of the data applicable for the org merge, and how should it map to the surviving org? Are there data storage requirements? How long will you need to store legacy data? Are there any data security concerns? Which users will be migrated and what permissions will they need in the surviving org? Which integrations will need to be updated? How are processes going to change? What is the testing plan, and how will you complete user training?
The final area to think through in the preparation stage is an org strategy that will allow you to effectively complete the work. Due to their complexity, org merge projects take time and multiple sprints, but that doesn’t mean all work in production comes to a halt. What sandbox will you use to stage the org merge work before deploying it to production? How will you keep the staging environment current with changes and hotfixes that are being implemented in production? 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?
ETL (exact, 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 linchpin to a seamless org merge, so make sure to allocate the time and attention it deserves.
Start with 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 loose data? Which objects should use audit fields for accurate reporting? For example, if you’re not careful with Opportunities, you could make it appear that you created and closed the legacy Opportunities on the same day, completely invalidating your average sales cycle.
With the object mapping complete, it’s time to think about field-level mapping. If the objects match, do the fields? If not, is the data needed in the surviving org and, if so, should the field be mapped to an existing field or recreated in the surviving org? Also pay attention to picklist values and any data standardization in the surviving org, since loading incorrect formats/values will impact reporting, validation rules, and general user experience. For example, if the surviving org uses Enterprise Territory Management to assign territories based on a two letter state/province code, the legacy values should be transformed before loading otherwise the legacy accounts won’t be assigned correctly in the surviving org.
Now that you’ve built out your org merge plan and ETL logic, it’s time to begin the merge process. Remember that you will need to keep the legacy org operational until you are ready to fully transition users to the surviving org, meaning you will need to run through the org merge steps multiple times to make sure you’ve caught all new/updated records.
A final note on integrations: The type of integration and stakeholder requirements will dictate when you can begin making changes. The earlier you can transition integrations that create/update records the fewer times you’ll need to run through the org merge process, but that’s not always possible. For example, you cannot update your legacy web-to-case forms until you have users that can resolve customer issues actively working in the surviving org.
Prodly can help automate the data migration and your Salesforce to Salesforce ETL work required during an org merge. Register for our webinar, Easier Org Merges, to see how we can help you prepare, build, execute, and assess your next org merge.