Your Acquisition Came With a Salesforce Org. Now What?

Four of our active projects this quarter exist because of an acquisition.

Not because anyone woke up wanting a CRM project. A company got bought, and now there are two systems, two processes, and a finance team asking for one forecast. If you're the acquirer's ops leader inheriting a Salesforce org, or the acquired team wondering what survives, the pattern across those four engagements is consistent enough to write down.

Inventory the automations before the records

The records are the easy part. What breaks quietly is everything bolted onto the acquired org. One acquired company's Salesforce didn't just hold pipeline; it triggered license-key generation for customers, provisioned training-platform access, synced finance data to the ERP, and auto-created renewal deals through the CPQ. Kill the org before replicating those and you haven't consolidated a CRM, you've broken fulfillment. The first deliverable in any consolidation is a list of every system the old CRM touches and what fires when. Only then can anyone estimate the real scope, because the answer is rarely "migrate Salesforce" and usually "rebuild four integrations that happen to live in Salesforce."

Same rule for the marketing side. One acquired company's content-engagement platform turned out to only support binding its API to a single marketing automation system at a time, which forced a webhook workaround during the coexistence period. You find these constraints by inventorying, or you find them in week nine.

The branding decision is the architecture decision

The question that unblocks everything: is the acquired company keeping its brand? Separate brands with separate go-to-market usually justify separate portals or business units. Full brand absorption points to one instance and a real merge. Teams stall consolidations for months trying to design architecture while leadership hasn't decided branding, and that's backwards; the org chart and brand strategy dictate the system design, never the reverse. Push for that decision first, even a provisional one.

Two practical notes from the field while you wait for it. Don't buy the new licenses until the project actually starts; buying at deal-close means paying for seats that sit idle through months of planning. And counterintuitively, absorbing a Salesforce org into HubSpot is often cleaner than merging two HubSpot portals, because a cross-platform migration forces explicit mapping decisions while a same-platform merge tempts everyone to assume fields mean the same thing. They don't.

Scope for the next acquisition mid-flight

If a PE firm owns the platform, assume another acquisition lands before your project ends. It happened to one of our clients this quarter: phase one expanded mid-flight to absorb a newly acquired division with its own homegrown systems and a second ERP. You can't prevent that, but you can structure for it: phase the work so each division onboards through a repeatable pattern rather than a bespoke build, and keep the deal-stage and data standards documented so the next bolt-on has a rulebook waiting.

The consolidations that go well aren't the ones with the fewest surprises. They're the ones where the integration inventory, the branding decision, and a repeatable onboarding pattern existed before the surprises arrived.

Inheriting an org right now? Start with the automation inventory this week. It's unglamorous, and it's the difference between a migration and an outage.