Org Merge Best Practices

Salesforce Org Merge Best Practices

A little over a year ago I gave a presentation to a local Salesforce Development Group (@MNSFDCDG) surrounding org merge best practices. Odds are, you were probably not in attendance. If you fall into this category, today is your lucky day! Below I have summarized the key points from my presentation including, how org merges should be conducted, as well as best practices that should be considered.

Why Merge Orgs?

First, why is there a need to merge orgs? The reasons vary but can be consolidated into a few categories:

1) Business Re-organization: when there is a need to merge multiple companies and/or consolidate business functions.

2) Realize Economies of Scale: when there is a need to facilitate management’s visibility into corporate data, enable team collaboration, and/or standardize data/metadata (which could entail streamlining change management, consolidating integrations, and/or enforcing data quality).

Org Merge Framework

Now, onto the high level org merge framework. When approaching an org merge, I structure the project around five phases: DISCOVER | DEFINE | DEVELOP | TEST | ROLL OUT. Each phase along with their key supporting elements and desired phase outcome(s) is detailed below:

Phase 1: DISCOVER

The discover phase is about understanding BOTH orgs current technology and process state. In order to gain this insight, it is recommended that stakeholders are identified and interviewed. Based on the information that is collected, process and architectural changes can be proposed. The next steps in the discovery phase are to identify opportunities for design/data cleanup and streamline business processes. If all of these steps are followed, you should develop a clear understanding of both existing orgs (their business processes and supporting design, the technical elements to be re-designed, and opportunities for improvement) and have made a first pass at what the future state of the merged org will look like.

Phase 2: DEFINE

During the define phase, you will determine which will be the target org (the org that will remain after the merge). Some of the driving factors in determining the target org include:

Design/process complexity: Integrations, APEX/Visualforce, business process maturity, Apps, Portals…
Data: Volume, complexity of relationships
Users: Number of users impacted

Typically the org that contains the more: complex design, mature business process, complex data nomenclature, and the most users will be the target of the org merge.

During the define phase it is also necessary to define the updated security model. Who will own merged records (assume a data migration is needed during the merge)? Also, make sure you understand how the merged users and their data and functional abilities apply to: Roles, Profiles, and Sharing Rules.

Finally, define the data to be migrated from the source org to the target org. This includes defining the scope of the data to be migrated, understanding how the migrated data will fit into the target orgs nomenclature / business processes / reports, and defining a data de-dupe strategy and the rules governing the de-dupe process.

A few best practices to consider surrounding data at this point:

Procure new user licenses in the target org that represent the users to be merged. Ensure the User object contains a LegacyUserID that reflects the old orgs UserID
Have Salesforce enable the editing of audit fields thereby enabling the update of the CreatedDate / CreatedBy fields during data migration
Define how design is to be merged / enhanced to support merged processes / usability / data

- Understand how the new design affects system limits (i.e. active workflow rules, sharing rules, various APEX governor limits, private reports, formula size, etc.)

Outcomes of the define phase include: a deeper understanding and documentation of existing and future business processes and supporting technical elements, a roadmap for the development phase, initial training detailing merged org process and functionality, and communication to users that sets the stage for upcoming changes.

Phase 3: DEVELOP

In the develop phase you should leverage an iterative approach for development / data manipulation. For instance:

Develop: Design & data
Review: Gain approval
Repeat: Repeat process when needed

You also need to keep data manipulation considerations in mind. Devise a data migration plan (understand and plan for how data migration will affect existing integrations, identify side effects that can affect data migration, and understand Salesforce limits) and know which tools to utilize when modeling / staging / migrating data (relational database verses a conduit between systems).

A best practice to consider surrounding data at this point:

Ensure each record migrated contains a LegacyID field tracking the original 18 character record ID.
Devise a metadata migration plan. Ideal situation is to move approved design to production in a hidden state ASAP and enable/expose said design at production go-live
Understand Salesforce limits (i.e. formula size, active workflows, sharing rules, various APEX governor limits, etc.)
A best practice to consider surrounding design at this point:

When possible, move approved design to target org ASAP keeping it hidden until production go-live

The develop phase is important because by engaging the stakeholders through the iterative development process, they gain a deeper understanding of future state design and process. In addition, communication to users sets the stage for upcoming changes.

Phase 4: TEST

During phase 4, testing occurs. All affected elements need to be reviewed. It is important to have a defined testing group from each impacted business function to test the process and design.

A best practice to consider at this point:

Perform at least 2 – 3 test migrations before the production migration.

At the duration of this phase, you will have a test system, the final state of merged design and data, as well as a full understanding of future state process and supporting design. In addition, you will have a proven migration process.

Phase 5: ROLL OUT

Prior to rollout, send a communication specifying login details to the migrated users. As stated earlier, ideally during rollout the supporting design would just need to be ‘activated / exposed’ in the target org leaving just the data portion to be migrated. Tools to utilize when migrating design between orgs include:

Metadata
- Data Eclipse or MavensMate
- ANT
Data
- Relational database
- Data Loader/Jitterbit/DBAMP/etc.

A few best practices to consider at this point:

Leave the ‘old’ org active for a period of time after production cut over: The org acts as a data backup as well as one can leverage the org as a data source for any post go live data migration work
Clearly communicate the migration plan and individual tasks to team members
Have on hand post migration expected record counts (counts derived from previous data migration iterations)
That covers it. One last comment, throughout each phase of the merge, make sure you communicate – communicate – communicate!!!

Written by Kevin Johnson, Lead Architect/Sr. CRM Advisor at Demand Chain

With more than twenty years of experience Kevin is highly skilled in enterprise software implementations, system integrations, identification of business requirements, team leadership, and project management. As a Lead Architect and Sr. CRM Advisor at Demand Chain, Kevin is responsible for all aspects of new and existing client engagements including: pre sales engineering, strategy creation, requirement gathering, process engineering, system design and integration, testing, data migration, training and go-live support.