This article is part four of a joint blog series with Simplus on things to consider when merging Salesforce orgs after a merger or acquisition. For an in-depth discussion on this topic with industry experts, register for our virtual event on February 10.
- Part 1: To Merge or Not To Merge?
- Part 2: Managing Integrations and Applications During Your Salesforce Org Merge
- Part 3: The Logistics of An Org Merge: Time, Scope, and Team
- Part 5: Merging Salesforce Orgs? Tips To Bring Down Storage Costs
- Part 6: The Business Side of an Org Merge
Working on a Salesforce org merge after a merger or acquisition can be such a time-consuming and grueling project, it can be hard to focus on anything else until those two orgs become one. In fact, for the project team responsible for completing a successful merge, it might be the only thing you work on for weeks or months.
For the rest of the company though, it’s business as usual. During an org merge, both the source and target Salesforce environments are live systems. And while it would certainly be easier if your data remained unchanged throughout the merge process, that’s not realistic. Your sales team won’t stop selling, which means new data will continue to be added to Salesforce, even as you migrate existing data. You can’t pause all Salesforce activity, but you can minimize downtime as much as possible for your users.
When we talk about downtime, there are two types: planned and unplanned. Even though the latter is scarier than the former, there are ways to minimize the effects of both.
Planned downtime
You’ll inevitably have planned system unavailability during the merge project. In fact, it should even be considered a best practice. By doing this, admins and developers are setting expectations with stakeholders that there will be system unavailability, and ultimately, changes or additions to the data and metadata.
Just like when you have scheduled downtime for other reasons (software upgrades, integration changes, etc.), try to schedule these for low usage hours whenever possible and always communicate planned downtime to users. The last thing you want is for a user to not be able to access Salesforce when he or she needs to make an important update to close a deal.
One thing that can mitigate the downtime effects is planning for a delta or incremental migration strategy. Incrementally loading records will allow you to move a bulk of the data first, then come back and perform a small delta migration to move what may have been changed in the interim. For example, if it will take you four weeks to move the data, users will be working in production in both orgs over that time. So at the end of that four weeks, you will need to migrate any records that were added or modified during the four weeks that you were completing the migration.
Unplanned downtime
While planned downtime you can well, plan for, unplanned downtime is another story. Although data migrations are often necessary for M&A, these migrations always pose a risk of creating duplicates or overwriting data. No matter how careful you are, mistakes are bound to happen when moving hundreds or thousands of records. Specifically, when merging metadata, configurations or code need to be reviewed. If not carefully monitored, these mistakes could set back your merge process by days or weeks and put your relationship with the other company at risk.
To combat these issues, make sure you have a comprehensive Salesforce data protection strategy in place. In fact, Salesforce recommends that you keep a regular backup of your data and do a manual point-in-time backup “before proceeding with any major data project within your organization.” The solution should include the ability to back up daily, monitor data changes, compare backups with previous backups, as well as completely recover Salesforce data, metadata, and attachments. With Own, for example, you can identify a data loss in real-time, quickly understand the extent of the loss with visual compare and find capabilities, and recover that data in minutes with just a few clicks.
Also, don’t wait until your “go-live” date to implement your backup. Many organizations wait to implement a backup solution until they have live data in their org. But having a solution in place pre-deployment will allow you to back up your sandbox environments and monitor any changes to your metadata as various developers and system integrators (SIs) prepare your environment for deployment.
For more on this topic, join our webinar on Feb 10th where we’ll discuss the top 10 considerations for Salesforce org merges during M&A.
.avif)
