At CloudKettle, Salesforce org mergers and Salesforce org migrations are a regular part of our business.
There is one question that is frequently raised by clients:
“Should we create a new clean org from scratch and migrate everything to it?”
This is not only the case for org mergers and org migrations, but also for clients dealing with older orgs that have a significant amount of technical debt and bad data.
The answer to this question, with few exceptions, is: DO NOT DO THIS.
Overview
Why shouldn’t you rebuild your Salesforce org from scratch?
When should you consider a new Salesforce org?
What should you do instead?
What to consider during a Salesforce org merger
Recap
Think about your org (or orgs as the case may be) as an apartment or house that is full of stuff. The sink drips, maybe some door handles are a little loose, but it is a roof over your head to keep your things in. Apologies if I stretch this analogy too far, but here goes.
Why shouldn’t you rebuild your org from scratch?
For most organizations, the reason their org is in bad shape is because of a lack of internal or external maintenance, a lack of data governance, a lack of overall org governance and quite simply, launching a new org won’t fix these problems. If your sinks are overflowing with dirty dishes, the bathroom is filthy and there’s a loud party every night so you can’t sleep – you can move to a new house with the same roommates, but if the rules aren’t tightened and people aren’t forced to change behavior – you’re going to be in the same spot in two months.
- When you decide to move to a new org, you have to freeze what you are doing in the existing org for a long period of time (generally the entire requirements, architectural and build process). It is much less when you merge one org into another. So essentially your roadmap hits pause for 6-12 months. Even minor improvements – replacing the leaky faucet, or repainting the baseboards – need to stop. In Salesforce terms, that means not implementing a new territory plan, not adding new integrations, not deploying new automations – that freeze needs to be in place so the new world can be built and the data migrated. This can be devastating to the business, often far outweighs the benefits of “starting clean” and seldom makes fans amongst stakeholders who can’t understand why their “one little thing” can’t be done.
- When you move to a new org, it doesn’t mean your data magically gets better. There is still a massive exercise that has to happen to clean and transform the data to move it to the new org (or merge data from two orgs into a new one). You need to take a hard look at your metaphorical closet, channel your inner Marie Kondo, and ask “does this spark joy”? Old processes, ancient data, etc. – these are things that need to be cleaned up and in some cases, thrown out, before you move. You don’t get to skip this step because you are starting fresh, in fact it is often more of an onerous process because you can’t do it in waves – it has to be tied to the major migration.
- Some integrations cannot be migrated from org to org. Much like custom countertops in a bespoke kitchen, in some cases an integration (like a Marketing Automation platform and its Salesforce org) mate for life. Meaning that if you are migrating to a new Salesforce org, you also have to deploy a completely new integration as well – significantly increasing the risk and scope of the project.
- Time to Value: Your users and stakeholders will not start seeing improvements until the end of a multi-stage project to migrate to a new org. You’ve purchased a new home, but moving day isn’t for 6 months. That is a long wait. When you begin to clean up the existing org and move new users in, the time to value is much faster. It might only be one release before the users in the “surviving org” begin to have an improved experience.
When should you consider a new org?
No rule in business is steadfast, there are always exceptions, but in this case they are few and far between. Here are some exceptional cases where migrating to a new fresh org might be necessary:
- You are an extremely large multi-national business doing a global migration of your ERP tool that is heavily integrated with Salesforce. If you have decided to undertake arguably one of the most complex system implementations possible and migrate and potentially merge an ERP system, then a net new org may make sense for you. Typically these projects take years and have entire teams devoted solely to them. There are the resources (human and financial) to make this succeed.
- You don’t have significant urgency and are okay to have a time horizon that starts at a minimum of 12 months to 2 years (depending on complexity) before the project can be completed. If you meet the criteria for the first bullet point, you are going to be closer to the 2 year mark than the 6 month as a minimum starting point.
- You are migrating down in your Salesforce license type. It generally is not possible to downgrade from say Unlimited to Enterprise. Doing so usually requires that the org be migrated to a new fresh instance.
- You are upgrading from a Sales or Service Cloud instance to a Salesforce Industries (Communications Cloud, Media Cloud, Financial Services Cloud, Energy and Utilities Cloud etc) instance. In this case you are adopting a new industry standardized data model and may benefit from replacing a significant amount of custom objects and other metadata with these new standardized, out of the box features of the new org.
What should you do instead?
For org mergers, where two or more orgs are going to be merged together, we recommend an Org Merge Audit and Roadmap in order to determine which org should be kept (become the surviving org), which should be decommissioned so that a plan and timeline can be built out before the project begins. An engagement like this is best done by experts who are experienced in migrations and will take about 6 weeks, but it significantly reduces the risk, changes there will be timeline and cost overruns and allows the organization to properly prepare for the migration. Consider 6 weeks a small price to pay for a roadmap that can prevent months of delays and unexpected scope creep.
After the audit and roadmap, generally, projects like this are best done in a phased approach. If more than two orgs are being merged, they are done one at a time – again, de risking the project and reducing the scope creep and cost overruns. Also the project should focus on the migration first and quality of life enhancements and new features being added as a followup phase once the migration is completed.
What to consider during a Salesforce org merger:
- Have someone with significant experience with org mergers and migrations audit what you have currently and provide advice on scope, but also on which org should act as the surviving org and which will be retired. This needs to include the org itself, but also the automation and integrations. In the case of acquisitions, it is often the case that the smaller, younger org of the acquired company is operated at a more sophisticated level and is the better option to keep. In our experience at CloudKettle, this is the case almost 50% of the time.
- As part of the migration project, ensure that new policies for Org and Data Governance and DevOps are instituted, including automation, duplicate detection and protections to enforce them. If you’re tired of muddy footprints all over the floor, the first step to success is making the kids take off their boots at the door before you start to mop up the mess.
- Once you have some better data and org governance in place, then start the data cleanup process. That includes removing duplicates, enriching records to improve field population, improving metadata (removing fields and objects no longer in use) and tightening up how and the quality of data entered by integrations.
- Begin the change management process early. Commit and budget for a final phase of the project that includes significant quality of life improvements for end users, but be clear and blunt that there will be some temporary pain during the merger process. Being honest that these changes will take time, but selling the other enhancements that are coming goes a long way to keeping stakeholders patient during the first phases of the project.
Recap
Starting fresh and rebuilding your org from scratch may seem like a tempting option, but in our experience, the costs far outweigh the benefits. While each merger/migration is unique and there may be certain circumstances where a greenfield deployment makes sense, it’s not a decision that should be taken lightly. Do your research. Talk to people who have done it before. Investigate exactly what needs to be done, and if possible – bring in some expert assistance so that you’ve got a clear approach before you make any major moves. These projects are not for the faint of heart – but with the proper planning and execution, can help you realize real efficiencies in your revenue operations.
