Marketing automation consolidation after acquisition: separate first, merge later

Marketing automation consolidation after acquisition works best when the acquired brands stay separated inside one instance rather than blended on day one. Workspaces hold each org's assets and programs. Person partitions hold each org's database, and every org keeps its own sending and landing page subdomains. Consolidate the platform and the licence first. Leave the brands alone until someone senior decides to retire one.

Why is one shared workspace the wrong first move?

Because merging two brands is a commercial decision, and by the time the platform team gets the consolidation request, nobody has made it. What lands on your desk is a renewal date and an instruction to get everyone onto one system. That is a contractual problem, and contractual problems end. The brand question involves sales territories, subscriber consent and a logo, and it will outlive your project.

The instinct is a single workspace. One scoring model, one lifecycle, one template set. It makes a tidy slide. It also means the acquired team's first send in the new system can reach the parent company's database, and it means that when the board decides later to keep both brands after all, you are unpicking a merged person database rather than deleting a workspace.

Collapsing a workspace later is a small job. Splitting a person database that has been merged for a year is not, and if consent records were flattened on the way in it may not be possible at all. So we keep the extra workspaces running longer than anyone wants, rather than merge a database twice. That is a conservative position and we are happy to defend it.

What actually keeps the brands separate?

One workspace and one person partition per acquired organisation. The workspace controls what a team can see; the partition controls which people exist for them; and a campaign cannot reach anyone outside the partitions its workspace has been granted. That last clause is the whole containment mechanism, and it is the sentence to put in front of an acquiring CMO who wants to know what stops the new team emailing everybody.

Each org also keeps its own sending and landing page subdomains, so the email that goes out the week after the deal looks like the one that went out the week before. Reputation follows the sending domain: fold an acquired brand onto the parent's, let their first act be a re-engagement send to a list nobody has touched since the announcement, and the parent's deliverability wears it.

The configuration — partition assignment rules, deduplication behaviour, which workspaces may see which partitions, and the DNS lead time nobody budgets for — is set out in the Pardot to Marketo write-up, because that is where those decisions actually get made. What follows here is the part that comes first: deciding what the organisation wants before anyone configures anything.

How do you sequence a marketing automation consolidation after acquisition?

There is a technical answer to this — start with the instance holding the most reusable logic, which is argued out in the Pardot to Marketo write-up. These are the organisational criteria that sit on top of it, and they usually win.

Start with the instance whose CRM alignment is settled — not the largest, not the friendliest. Partition assignment, lifecycle, routing and sync error handling all sit downstream of which Salesforce org survives and which is being merged into it. Until that is answered you are building on something that moves.

After that, the ordering criteria we actually use:

• Contract end dates. A Pardot renewal is a date, and no amount of architectural argument moves it.
• Integration count. The instance carrying the webinar platform, the enrichment tool, the routing layer and whatever Zapier has been holding together needs the most runway, not the least.
• People. Whoever knows why that smart campaign has a wait step in the middle of it tends to be somewhere else by the time you need them. People leave after deals close. Interview them at the start of the project, not the end.
• Program weirdness beats program volume. A pile of one-off email programs migrates faster than a handful of engagement programs with custom cadence and stream transition rules.

There is a strong pull towards starting with the politically easy instance — small, tidy, cooperative stakeholders — and building the shared operational programs against its data model. Do that and you build the shared layer twice, because the next org's data will not fit it. Build against the messiest org even if that org migrates second.

Expect the website to be its own workstream. On an Eloqua-to-Marketo migration for an aviation agency — a different situation, the same lesson — the site's data-collection layer was bespoke enough that form handlers didn't cover it, so the whole capture layer had to be rebuilt. That is not asset migration. Scope it separately or it eats the timeline.

What do you do about duplicate people records across the orgs?

Leave them duplicated, deliberately, at least at first. Marketo deduplicates on email address across the instance by default, but partitions can be configured so that deduplication happens within a partition — the same address existing once per org. That is usually what you want. Someone can be a customer of one acquired brand and a cold prospect of another, with different consent and unrelated history.

Merging those records is a business decision wearing a data task's clothes. Two questions settle it: which legal entity collected the consent, and whether that entity survives the deal. If the acquired company keeps its identity, its subscribers did not agree to hear from the parent, and no partition configuration changes that. A re-permission programme is often the honest route, and it will cost you records.

What not to merge:

• Behaviour score. Two models, two definitions of what a qualifying action is. Adding them produces a number that means nothing. Rescore in the surviving model.
• Lifecycle stage. Same problem, more visible in the pipeline report. MQL in one org was a demo request; in the other it was a gated PDF.
• Activity history. It does not come across. Put that in writing at kickoff rather than in an apology later.

Suppression is the exception. Unsubscribes and hard bounces should be pooled and applied across every partition, even where consent records stay separate. Over-suppress — nobody has ever complained about an email they didn't get. Reconciling suppression exports that arrive in different shapes, with different ideas of what unsubscribed means, is the dullest part of the whole project and the part that keeps you out of trouble.

Who owns the instance after the deal closes?

One team owns the instance, and workspaces are tenancies rather than territories. In practice the admin role stays with a central marketing ops function, workspace users get a role scoped to their own workspace, and field creation or anything touching the CRM sync goes through the central team as a request.

• Field bloat is the tax for skipping this. Each org arrives with its own version of the same field under its own name. Map to one shared field only where the definitions genuinely match, and keep the per-org field where they don't — a harmonised field averaging two different definitions is worse than two honest ones.
• Naming conventions get agreed before the first program moves. Retrofitting them across a migrated instance is slow, graceless work and nobody volunteers for it.
• The sync user is one account. Acquired-org admins do not get its credentials, however senior they are and however the conversation goes.
• Someone owns deliverability across every subdomain. That someone is not the brand teams.

This question surfaces late and gets decided by whoever pushes hardest in the meeting. Settle it in a document with a named owner before the first asset moves. Once migration is done everyone is busy, and instance ownership becomes whoever happens to be free.

Frequently asked questions

Can acquired brands keep their own look and sending identity after consolidation?

Yes, and saying so early is worth more than it sounds. Sender identity, tracked links and landing pages all stay per brand, and once DNS has propagated recipients see no change. The consolidation is a licence and infrastructure change, not a rebrand, and conflating the two is how these projects acquire opposition they never needed.

Should we move to one instance or keep the acquired instances running?

One instance, with workspaces and partitions inside it. Separate instances mean separate licences, duplicated operational programs, duplicated integrations and no shared reporting — and every change gets made two or three times, slightly differently each time. One instance with proper separation gives you the isolation of separate instances, plus a single sync user and one place to look when something breaks.

Does activity history migrate between marketing automation platforms?

No. Email opens, clicks, form fills, web activity and score change history stay in the source system. You migrate assets, programs, lists, people and field values — not the activity log behind them. Plan for a period where reporting is split across old and new, keep read-only access to the source instance until the reporting year closes, and export anything the business genuinely needs before the contract lapses.

What determines how long a consolidation takes?

The number of live integrations, whether the CRM org question is settled, how much bespoke website data collection exists, and how many engagement programs with custom stream logic need rebuilding rather than copying. Asset counts matter far less than people assume. The largest single variable is availability of someone from the acquired side who can explain why a given program was built the way it was.

Who should own the instance once the deal closes?

A central marketing operations team, with the admin role held there and workspace-scoped roles for everyone else. Acquired brand teams keep full control of their own workspace — programs, assets, campaigns — while field creation and anything touching the CRM sync stay central. Without that split you get field bloat and a sync nobody owns, and both are much harder to unpick a year later.