A 6-Point Checklist for Merging Organizations in Salesforce

Companies managing multiple Salesforce instances often need a single integrated view of process and customer data that cannot be stitched together across multiple instances while maintaining high data integrity and excluding duplicates. At this point, merging organizations in Salesforce from separate instances into a single consolidated organization may present the best long-term solution.

Organizational mergers involve several technical and project management challenges that should be considered in advance. In this guide, you’ll learn what a Salesforce organization merger is and the steps you must take to prepare for one.

Watch this video to learn more about Org Merge Best Practices.

What is a Merging of Organizations in Salesforce?

Salesforce supports three ways to merge existing organizational instances. Each offers varying sets of pros and cons. Companies should evaluate their own circumstances to determine the best solution in any case.

  • Single Organization: Migrates data from two or more organizations into a new single organization.
  • Reporting Organization: Creates a new organization to collect and report data from various other organizations.
  • Parent-and-Child Organization: Assigns an existing organization to another in a parent-child relationship with a one-way flow of data and structural changes.

6-Point Checklist for Salesforce Organization Mergers

Here are six points that should feature in any Salesforce organization merger plan.

1. Approach Methods: Speed or Optimization?

The circumstances that precipitate organizational mergers vary widely. For this reason, merger plans may have different goals and priorities.

When speed is critical and the merging organizations have structural and functional similarities, it may make the most sense to use what is known in cloud computing as a lift-and-shift strategy. Lift-and-shift prioritizes moving application architectures as wholes and refactoring after deployment. The major pro-con balance here depends on the compatibility of the merging organizations. High compatibility will benefit from low upfront costs and minimal refactoring costs.

Alternatively, merge designers can accept higher upfront investment and a long deployment cycle to optimize each merging organization up front to yield a high-functioning, high-integrity merged organization out of the box at deployment. Features you should consider for tweaks and adjustments include:

  • Workflows
  • Validations
  • Fields

2. Editions and Sandboxes

Prior to data migration in a merger, you’ll need to ensure edition compatibility and secure the necessary sandboxes for testing. Sandboxes are developer tools for testing configurations in controlled environments. Sandboxes can contain the custom features of an application such as fields, code, and automation and – in some cases – its data as well.

Salesforce sandbox license types.

Salesforce offers four sandbox types that differ according to their storage capacities, refresh rates, and data/metadata handling. These are:

  • Developer Sandbox
  • Developer Pro Sandbox
  • Partial Copy Sandbox
  • Full Sandbox

Salesforce recommends for any merger at least one developer sandbox for metadata and code migration and one full sandbox for data migration and end-to-end testing.

3. Metadata Considerations

Before migration, your teams should identify potential issues and incompatibilities in the metadata of merging organizations. Key considerations here include:

  • Include all profiles and permissions sets when you extract metadata from the source organization. Excluding these causes the loss of shared visibility settings.
  • Identify unsupported metadata types that must be migrated manually.
  • Validate metadata against production a few days before going live to avoid losing time running the same unit tests multiple times.

4. Common Versus Distinct Code

Separate Salesforce instances will contain code common to the platform – and therefore shared implicitly – and distinct code that is unique to a particular organization. A successful merger will require accounting for all common and distinct codes in your organization. It will likely involve some custom workarounds to avoid exceeding baseline Salesforce limits, such as unique object references.

In most cases, workarounds entail writing a considerable amount of new code. Taking this into account, you should dedicate sufficient developer staff to the project. Cutting corners here may run you up against Salesforce’s platform requirement of 75% code coverage – a standard developer metric for determining how many lines of new code require testing – for live deployments.

5. Deployment Plan

As mergers will invariably involve the coordination of multiple teams, you should articulate as soon as possible a detailed deployment plan. This plan should enumerate tasks by type with corresponding descriptions and should be circulated to all relevant teams early in the process.

A sample deployment plan for a Salesforce org merger

Deployment plans should include for each task:

  • Order relative to other tasks
  • Owner
  • Estimated Runtime

Accurately estimated runtimes become increasingly important as you attempt to gauge whether your team can complete the merger migrations within a specified timeframe. Failure to account for runtimes in your deployment plan can mean backtracking to this step before going live if your organizations are too large and active to handle extensions to system downtimes.

6. Data Migration

As better data integrity and strategic data management are often the driving goals behind organizational mergers, you’ll want to plan your data migration in as much detail as possible. Migration will likely be the single longest-running task in the merger process. If both merging organizations are currently live, each will continue accumulating new data to migrate. Establishing a feasible timeline for the merger is critical so your staff can coordinate seamlessly.

Depending on the complexity of your platform, you may need to use a custom toolkit of AppExchange resources. These may include:

  • FieldTrip: To assess field usage and possible field removals.
  • com Migration Tool: To extract and deploy metadata.
  • Tableau: Data transformation.

When migrating data from an organization that will be destroyed in the merger, take the time to prune your data with clearly defined selection criteria. This will ensure a cleaner running organization on the other side of the merger and reduce storage costs.

Salesforce Full Project Delivery with Rainmaker

Rainmaker specializes in providing Salesforce clients with full project delivery from discovery to ongoing change enablement. Rainmaker’s multi-disciplinary team of consultants can help you thoroughly identify risks and assess project readiness throughout your organization.

To learn more and chat with a team member, contact Rainmaker today.

Related Resources