This article is part five of a joint blog series with Simplus on things to consider when merging Salesforce orgs after a merger or acquisition.
- 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 4: How To Avoid Downtime When Merging Salesforce Orgs
- Part 6: The Business Side of An Org Merge
Over the last month, we’ve been focusing a series of blog posts on the inevitable data impacts surrounding business mergers and acquisitions. It’s a new year, and many are predicting that M&As will pick up pace in 2021, building on a 33% increase in deal volume and a 140% increase in deal value in Q3 over Q2 of last year. With more M&A activity also comes more IT integration projects, and one of the most important (and complex) of those is often the process of merging multiple Salesforce CRM orgs.
Especially if your company (or the one you’re merging with) is a long-term Salesforce customer, your collective instances might contain hundreds of fields, thousands of users, and millions of records. Given the mission-critical value of all this information, once you’ve decided to combine Salesforce orgs after a merger or acquisition, it’s important to prepare for every potential challenge. Naturally, you’ll want to preserve as much historical corporate memory as possible for both companies, but you should also consider how the org merge will impact storage space required in Salesforce, and, of course, associated costs.
This is a common problem, but not one that’s easy to manage. Let’s review three typical scenarios:
1) Migrate everything from the acquired org or orgs, expanding your storage usage and costs.
If you’re in a time crunch to get the integration work done, this might seem like your best choice. However, it could suddenly double or triple your data and file storage needs. In addition to increasing your costs, keep in mind that another downside could be slower system performance and potential non-compliance risks. Data volume itself will not impact your performance, but the number of records you include on a report could. So if you really need all of the records you are migrating in, you need to consider your report filters, indexing, and other related functionality.
You may also have regulatory and compliance considerations for how long you can or need to store data that you should keep in mind. For example, state laws may require you to keep medical records for a certain length of time, or you may have internal corporate data retention stipulations.
Before heading down this path, make sure you know approximately how much storage your existing Salesforce orgs are using (and on what objects), so you can accurately forecast monthly and annual space requirements and make sure you’re prepared for the long-term costs.
2) Migrate everything from the acquired org(s) and archive data and attachments based on established policies.
It is important to research the hard limits in Salesforce and compare those costs with the fees for adding Salesforce data or document storage, or for moving it outside the system. One common example is large data storage. If you need to store very large documents, it may make sense to integrate an external solution that’s dedicated to storing large files.
Some manage this process manually, but if you have a high volume of documents, technology integration is the way to go. Many adopt some type of Salesforce Connect add-on, which lets your users view, search, and modify data that’s stored outside your Salesforce org. Instead of copying the data into standard or custom objects, you can use external objects to access the data in real time via web service callouts. You can also look into more robust, automated archiving tools, like a connected app from the Salesforce AppExchange. Own Archive, for example, enables users to create and manage custom archiving policies to automatically archive data from within your Salesforce production environment.
There is a lot to consider, so be sure to plan enough time to get this workflow right.
3) Back up the acquired org(s) and hold off on migrating indefinitely.
This option might involve shifting newly acquired sales teams onto one of your existing Salesforce instances as your primary operating platform for all data capture and activity going forward. But, even if you’ve migrated key data over to the primary org, it’s still a good idea to maintain access to the old org for a while. Typically, you can keep just one admin user active for a year or some reasonable amount of time to cover your bases. This will help if unknowns arise or things get missed during the transition.
You’ll want to be able to easily find data, rather than having to go through a bunch of backup files with interconnected data tables. Otherwise, you might be spinning your wheels trying to reproduce relationships just to get a quick answer. Definitely make sure you back up all data prior to starting the change management process, and be sure to lock edits to the acquired org so that it truly is just a backup and you won’t get stuck having to do additional delta migrations. Finally, don’t forget to prepare a final backup before turning off the old org after that post-acquisition period is up.
At Own, we’ve seen many customers gain huge TCO savings from the second and third approaches while enjoying the added benefits of faster recovery and more robust data protection. Of course, storage costs are just one concern during a Salesforce org merge. Our previous blogs on this topic cover scenarios like downtime handling, integrations, as well as best practices surrounding time, scope, and team.
