I recently spoke to a friend of mine who’s in a new leadership role. One of his main challenges? His lines of business are spread across 10+ Salesforce orgs thanks to a series of acquisitions over many years.
If you’ve always worked in startups or companies that have developed a strong integration muscle, a baker’s dozen CRMs floating around sounds utterly insane. But if you've ever worked in a PE-backed company or one that’s recently gotten acquisitive without prioritizing ops, you’re nodding along right now.
I found myself in just such a position in my last RevOps leadership role. I inherited a hastily assembled RevOps team and found myself responsible for 11 different Salesforce orgs. It was the same basic story: years of PE-driven acquisitions where the primary integration concern was the P&L and nothing else.
This is way more common than you might think.
Multiple CRMs can happen to you
After talking to hundreds of sales teams, I’ve learned that when you look closely at the GTM org of an objectively successful company, you’ll usually find more duct tape and bailing wire (as my dad likes to say) than fine craftsmanship.
It pains me to say it, but PMF beats operational excellence every day of the week—at least up to a point. Eventually, a poor foundation causes problems, especially if the board has decided they’re determined to build a skyscraper by buying new floors to stack on top of what began as a 3-bedroom family house.
Sure you could rebuild the foundation, but that’s expensive and—perhaps worst of all—slow. There’s a lot of pressure to quickly start realizing value from any acquisition. There will be culture, process, brand, product, and 1,000 other differences that often make leadership decide to operate the new org independently “in the near term”.
The “near term” has a habit of expanding into “medium term” and perhaps even “long term”. This means CRMs stick around longer than anyone wants because it’s usually most expedient to keep operating separately. Nobody intentionally sets out to have 10+ Salesforce orgs, but combine enough expedient decisions over time and there you are.
Eventually the cracks in the foundation become too big to ignore. Customers complain about reps from different product lines calling them willy-nilly, leads get dropped as routing becomes a combinatorial nightmare, and reporting fragments into narratives emerging from completely different data sets. The pressure shifts towards consolidation.
The rest of this article includes some lessons learned from my experience dealing with a multi-CRM situation that had become untenable. We didn’t get everything right, but we did make meaningful progress with an improved data layer and some major CRM consolidation. Best of all, we did it without any significant disruptions or slowdowns.
I’ll start with one mistake we most definitely did not make: burning it all down and starting over.
Avoid “The Big Rebuild” at all costs
As I’ve mentioned many times in this newsletter, I used to be a software engineer. I’ve built and maintained some pretty big systems. I learned a few things about what you should and shouldn’t do with heavily-used software.
Any sufficiently established CRM is custom software. This is especially true of Salesforce but applies to any CRM that allows customization (i.e. all of them). Eventually it grows custom fields, objects, workflows, validations, UIs, even code—and that’s before you consider all the ways in which it might be integrated with other parts of your tech stack.
Then remember this customization happens over years, with a revolving door of admins on top of what is essentially a database that anyone in the company can edit. It’s guaranteed not to be pretty.
Staring down a mess like that, it’s natural to think you should just start from scratch. After all most of that stuff was built for old ways of doing things. With the benefit of hindsight and without having to support all this legacy stuff, surely you can do better.
The problem is that a big part of the stuff that feels like cruft actually matters—it’s just hard to tell exactly which parts. Maybe some workflow is super important for a key report. Maybe there’s a validation taking care of some edge case you’ve never heard about (because it never breaks anymore). Maybe some internal product system depends on a piece of CRM data being just so.
One of my favorite essays on software engineering is from Joel Spolsky (a founder of both Trello and Stack Exchange). It’s titled Things You Should Never Do and it’s about how Netscape killed themselves by losing their market leadership during a 3-year rewrite between Netscape 4 and Netscape 6 (there was no version 5).
The article’s 25 years old now, but the principles are timeless. He nukes the rationale for rewrites:
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around...
[…]
It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.
Substitute CRM customization/workflow/etc for “code” and you’ll see what I mean.
These fundamental truths mean that—like Netscape in the late ‘90s—your rebuild will take longer than you expect. Several months ago, I saw a slide deck from a company building a “greenfield” Salesforce. It had what looked like 8 duplicate Gantt chart slides. When I looked closer, I realized that each slide was a snapshot of a previous project plan. It was a history of how many times (so far) the project had slipped. This is the norm, not the exception.
And during the time you’re building that new CRM? You’re keeping the the old one(s) in maintenance mode, making as few changes as possible. The business is stuck like Netscape. As Joel Spolsky puts it:
You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don’t have shippable code. You might as well just close for business for the duration.
Can you afford to keep your existing CRMs in stasis for an extra year or two while the big rebuild slips 8 times?
So what do you do instead? Three things:
Improve incrementally - Push your ops team to identify problems and fix them systematically, not throw up their hands and say they need to start over. Of course you’ll need to do this in each CRM, which obviously isn’t great. But it’s better than being in a holding pattern for months.
Connect your data - The problem with multiple CRMs is that the data and processes live in silos. You can break those down without rewriting the world.
Consolidate (Highlander-style) - Pick a primary CRM and systematically merge the others until there’s only one left.
Let’s look at a bit of hard-won experience on how to get data flowing and begin to tackle an actual consolidation effort.
Build data bridges
Just because you’re dealing with multiple CRMs, it doesn’t mean they have to stay completely siloed. In fact, you should move as quickly as possible to get them sharing data in a reasonable way.
There are entire disciplines, massive products and large consulting shops devoted to tackling this kind of problem1 so there’s no way I can give you an exhaustive picture here. That said, I’ll just focus on two tactics that can get you some wins:
Direct Links - connect key records and data from one CRM to another. This works best in scenarios where you just need 1:1 visibility between two CRMs. This has the benefit of being something you can stand up quickly. Let’s say you acquire a new company, AcquiCo. You can set up a recurring process that matches2 the accounts in your primary CRM to AcquiCo’s CRM and updates a field on each side to show ownership in the other org. This means reps in one CRM can quickly see who owns the account in the other CRM.
Centralize Data - pull a copy of relevant data out of the various CRMs and into a centralized database (i.e. a data warehouse). There are all kinds of challenges once the data is in the warehouse—ranging from handling deletes to “resolving” many records into one (e.g. deciding that two Account records from different CRMs refer to the same company). This data won’t be the operational “source of truth” for the reps who still work in any one CRM, but it can be the foundation for executive visibility and reporting.
In my last role, we did both of these.
Almost immediately after my startup got acquired, we set up a limited bi-directional sync between the startup’s and the acquirer’s Salesforce orgs. The goal was basic: connect overlapping accounts and some limited opportunity data in both systems. The two companies had previously been fierce competitors so this got quick visibility into the myriad sales cycles we would have to de-conflict.3 It also helped reduce (but not eliminate) the number of new conflicts that cropped up during the early days of the integration.
As we got settled in and I started to spin up a new BI function, we got our hands on Domo4 (the company already had a license), which we used as a combination data warehouse and reporting tool. We eventually got access to all 11 Salesforce orgs and starting to sync their data into Domo. Slowly, but surely, we were able to build a fairly consistent data model and reporting views that spanned all the Salesforce orgs in a reasonably consistent way.
In both cases, don’t let perfection be the enemy of progress. Some visibility now is almost always better than perfect5 visibility in 6 months.
These various data linkages allowed us to have more visibility and more operational flexibility in a multi-CRM world while we plotted how to begin consolidation.
Which brings me to a few words on running a consolidation process.
So you’ve decided to consolidate
As you may have gathered from the “big rebuild” section, I’m very much against the idea of creating a new “greenfield” CRM and attempting to merge all the other CRMs into that. Instead, I see this as a Highlander scenario: one of the existing CRMs should win out and be the last one standing.
Most of the time, choosing the “primary” CRM should be straightforward. In almost all circumstances, just pick the one that represents the most business being transacted by the most people. From there, it’s a series of merges of each of the other CRMs into the primary.
Obviously I’m not going to try to tell you everything (even if I knew everything) you need to know to do a CRM merge here. What I can share is one simple tool that helped me organize a a successful process.
Whenever you consolidate CRMs there are data issues, technical integration issues, process issues, policy issues, you name it. But more than anything else, there are decisions—hundreds of big and small decisions have to get made. One of the things that makes these processes takes so long is that these decisions move slowly. They get tied up in committees or punted because nobody wants to step up and make them.
The best thing we did was start with a framework for decision making. It started with a sheet like this:
We made a list of our major GTM processes and for each process area, we assigned Owners and Domain Experts from each side.
Owners are the senior-most executives responsible for that process. For example, the Owners for Outbound might be the VP of Business Development in Org A and the Director of SDR in Org B.
Owners are responsible for one thing: making decisions about that process area. They’re not responsible for surfacing the decisions that need to be made—that’s the integration team’s job—but they’re responsible for arriving at a decision when one is required. Want to use pools instead of pods for SDRs in the merged org? These folks make that call.
Domain Experts know how each process actually works for each org. They understand the data model and the actual workflows. They might be a manager or a really operationally-minded rep. They work with the integration team to answer questions about how everything works and how changes will impact day-to-day work. These folks were heavily involved in our consolidation process—from process documentation to user acceptance testing.
I’m firmly convinced that setting up this process right from the jump did two really important things: a) radically sped up decision making and b) created a bunch of domain experts with a stake in the success of the project who could evangelize to the rest of the sales floor.
The result was a major Salesforce consolidation that came in on time and on budget.
Wrapping up
I’ve only barely scratched the surface of an enormous topic here. There’s a lot of moving pieces and everyone’s multi-CRM situation is a little different.
Hopefully this gives you the will to push back (hard) if someone tells you you should do a big rebuild while also pointing to some concrete things you can do to make living with multiple CRMs less painful by breaking down your data silos.
Once you do go all in on consolidation, optimize for speed and quality of decision making first. That will smooth the way for everything else.
Some people might use words like “topologies” but I’m not going to do that to you.
Start by just matching on account websites/domains and improve the matching as you go. These scenarios often favor implementation speed over precision. If you wait until you have a 99% match rate with no false positives or negatives, you’re going to miss out on months of value from being able to quickly see most important overlaps.
The full work of de-conflicting is a story for another time.
Which you’ll never achieve anyway.