A group we worked with last year ran four brands, built up over several years. One did risk assessments. One supplied equipment safeguards. One made the safety labels that went on the equipment. One did industrial printing.
Their customers moved between those brands in a natural sequence. Assess the risk, fix the hazard, label the result.
It is a genuinely good acquisition thesis: buy the adjacent step, sell the whole journey.
The journey was real. Nobody could see it.
When a lead arrived, it was often unclear which of the four companies should take it. One brand's team cross-sold as a matter of course. The others did not, because they had no way of knowing what a customer had already bought.
Leadership ran group reporting off manual rollups.
Underneath, the estate looked like this:
- Every brand had its own marketing tool, separately configured, built up over five years
- Tens of thousands of contacts across them, with no way to tell how much overlap there was
- The operational system held products, pricing and orders, but service quotes happened entirely outside it
- Lead capture ran through a third-party form tool
- The gaps were filled with spreadsheets and a shared drive
This is what digital fragmentation actually looks like. Not a bad platform choice.
A set of reasonable local decisions, made by different companies at different times, that nobody was ever asked to reconcile.
Seven layers, all duplicated
Before going further, it is worth being precise about what "digital fragmentation" covers, because the CRM is the part people name and the smallest part of the problem.
An acquisition duplicates all seven:
- Presence and content. Two websites on two content platforms, two content models, two sets of brand assets in a drive you do not have access to
- Discoverability. Two domain estates, two sets of redirects, two search footprints, duplicate business listings and separate ad accounts. This is the layer that quietly loses money when brands are retired badly
- Commerce. Two storefronts, two catalogues, two pricing structures, two checkout and fulfilment paths. The group in this piece ran two different commerce platforms across its brands
- Customer data and engagement. CRM, marketing automation, service and forms. The layer everyone names
- Operational systems. ERP, finance, quoting and inventory. Usually the oldest thing in the building and usually the thing that should not be replaced
- Measurement. Two analytics setups counting slightly different things, and two sets of reporting definitions that have never been compared
- Foundation. Two hosting arrangements, two security postures, two accessibility positions, and two sets of vendor contracts with different renewal dates
Most consolidation programmes budget for one of these. Usually the fourth.
The one that produces the fastest visible loss is the second. When a brand is retired and the redirects are wrong, the search equity built over fifteen years goes with it, and the traffic does not come back by itself.
The one that produces the slowest, most expensive loss is the sixth. If measurement is never reconciled, every decision made after the deal is made on numbers that cannot be compared.
What follows is a worked example from the fourth layer. The principles underneath it apply to all seven.
They had already tried once
The detail that mattered most was not in the stack. It was in the history.
They had attempted a CRM implementation before, and it had not stuck. Four things went wrong, and we now hear them almost verbatim at other groups.
Data sync failed. Duplicates multiplied with no agreed way to resolve them. Nobody was clear who owned which process.
Then adoption collapsed, because the system was complex and people did not trust what it told them.
That last one is the real failure. The others are engineering problems. Trust is not recoverable by shipping a fix.
Once a sales team has decided the system is wrong, they go back to the spreadsheet. And every report built on that system afterwards inherits the suspicion.
So the second attempt is a different project from the first. It is not judged on features or migration speed.
It is judged on whether the numbers survive the first hard question in a leadership meeting.
Most acquisitive groups we meet are on their second attempt. If you are on your first, the most useful thing you can do is find out what the companies you bought tried before you bought them.
What we actually believe
Five things, in the order we apply them. They came out of the work rather than a framework deck, which is why they are specific.
One. Map every brand's current state before drawing a single future state.
The instinct is to design the target architecture early. It feels like progress and it is what gets asked for. We deliberately refused.
The reasoning was blunt: a future state that makes sense for the largest brand will not survive the other three arriving. So we mapped all four end to end first, and only then designed the consolidated model.
Our test: can we describe how each brand works today well enough that the people who run it say "yes, and you missed this one thing"?
If they are correcting the shape rather than the detail, we are not ready to design.
Two. Sequence by layer, not by brand or by ambition.
There is always pressure to do everything at once, usually with good intentions. Marketing wants to start while sales is still being built, because waiting feels wasteful.
We sequenced it instead: get one layer right, with the data flowing and verified, then move to the next.
Not because phasing is virtuous, but because each layer depends on the one beneath being trustworthy. Marketing automation built on an unverified customer record produces fast, confident, wrong outcomes. Which is precisely how the first attempt failed.
Phasing also means the first thing that goes live is small enough to be checked by the people who use it. That is how trust gets rebuilt: in increments.
Three. Build the integration to outlive the systems it connects.
The operational system at this group was under review. A replacement was being evaluated, with a horizon past the following year. Nothing was decided.
Most integration approaches assume both ends are permanent. We built the connecting layer so the operational side is a replaceable adapter, speaking in business concepts rather than one system's field names.
If that system is replaced, the adapter changes and everything above it does not.
That costs more up front, and we said so. It is only right when a platform change is genuinely plausible. Here it was. If both ends are staying for a decade, buy the connector and spend the money elsewhere.
Four. Resolve identity on more than one key, and do it first.
Duplicates were a named reason the first attempt failed. So identity resolution moved to the front rather than being scheduled as cleanup.
We matched on three keys, not one. The third is the one most consolidations skip, and it is usually the only one that is actually unique, because the finance system has been enforcing it for years.
By the time anyone notices duplicate-driven errors, a quarter of decisions have been made on them.
Five. Keep brand as a dimension, not a wall.
The obvious answer to multiple brands is multiple instances. It is tidy, it maps to how the business feels, and it recreates the exact problem you are trying to solve.
We used one environment with brand as a structural dimension inside it. That let two things be true at once: each brand keeps its own assets, campaigns, teams and lifecycle definitions, while the customer record stays single.
The payoff is a sentence the old setup could not express:
This customer is an existing account for one brand and a brand-new prospect for another.
That is the cross-sell opportunity stated as data rather than as a spreadsheet exercise. It is also the thing the acquisition was justified on in the first place.
The part nobody schedules
The hardest work was not technical. It was vocabulary.
Across four brands the same words meant different things, and the same events were counted at different moments.
Team structures did not match either. One salesperson covered several brands. Another brand had a dedicated team. Only one of them had a cross-selling habit. Lifecycle stages had evolved independently and inconsistently.
None of that appears in a field-mapping document.
All of it breaks reporting the moment the systems start talking, because now four definitions collide inside one number instead of sitting quietly in four separate systems.
We spent longer on definitions than on code.
That is not a complaint about the client. It is the normal shape of this work, and any plan that does not budget for it is wrong. It also cannot be delegated to the engineering team, because it is a commercial decision about how the business describes itself.
What this means if you are acquiring
Three things, and none of them require choosing a platform this quarter.
- Ask what the target tried before. During diligence, not after close. A failed implementation inside an acquired company is a liability you are buying, and it is cheaper to know about at the term sheet than in month four
- Decide what owns the customer and what owns the transaction. As a commercial decision, before anyone configures anything. Most of the architecture follows from that boundary
- Build the fold-in as a capability, not a project. If you acquire every few months, the valuable asset is not a tidy estate. It is a repeatable way of absorbing the next company: what migrates, what retires, who decides, and how long it takes
That last one is what turns an eighteen-month surprise into a known number at the term sheet.
The group in this story is live now. The thing we would point to is not the platform they ended up on.
It is that four brands can finally see one customer, and that the people using the system believe what it tells them.
The second one took longer to earn than the first.