Most groups arrive at the question of consolidating multiple CRM systems into one after years of putting it off. Each trading company bought its own platform at a different point in its life, configured it to its own habits, and the group has been reconciling the output in a spreadsheet ever since. The decision to merge is usually the right one. The anxiety attached to it is almost always pointed at the wrong risk. Finance worries about losing the records. What actually disappears is everything that made the records mean something.
Executive Summary
Consolidating multiple CRM systems into one is a data ownership exercise dressed as a data migration. Contact and company records transfer reliably; what degrades is the surrounding context, including stage definitions, owner semantics, custom fields that encoded local meaning, and the audit trail of who touched an account and when. Gartner's research puts the average annual cost of poor data quality at at least $12.9 million per organisation and names inconsistency across sources, the direct product of siloed systems with overlaps and gaps, as the hardest data quality problem to solve. The three decisions that determine whether the group's history survives are made before any field is mapped: which legal entity is the controller for each record, who owns a customer that appears in more than one instance, and what the permission model must allow between brands once everything sits in one place. Groups that settle those first can treat the technical migration as the straightforward part, because it is.
What actually gets lost when you consolidate multiple CRM systems into one?
Records are the easy part. Every serious platform will export contacts, companies, opportunities and notes, and any competent migration will land them in the destination with their names and values intact. The loss happens one level up, in the layer of meaning each instance built around those values over five or eight years of use.
Consider what a sales stage actually is. In one trading company, "Qualified" might mean a site survey has been booked. In another, it means someone answered the phone. Both export the word "Qualified". Once they land in a single pipeline, the group has a conversion rate that is the average of two incompatible definitions, and no way to tell them apart unless somebody deliberately preserved the original label and the entity of origin as attributes on the record. Gartner identifies inconsistency across sources as the most challenging data quality problem organisations face, precisely because it is the product of data being maintained separately with significant overlaps and gaps (Gartner, Data Quality).
The same applies to custom fields. Every long-lived CRM instance accumulates a handful of fields that carry disproportionate weight: a "credit status" picklist that the finance team actually trusts, a free-text field where account managers record the renewal politics, a flag that marks accounts the MD has asked to be left alone. None of those appear in the destination's standard schema. In a migration run to a deadline, they are the first things dropped, because mapping them requires an argument with a busy person about what they mean.
Figure
The standing cost of inconsistent customer data
$12.9m
Average annual cost of poor data quality per organisation
Gartner research, cited 2020 onwards
59%
Of organisations do not measure data quality at all
Gartner surveys
Separately, MIT Sloan Management Review estimates the cost of bad data at 15% to 25% of revenue for most companies.
Source: Gartner, Data Quality research
MIT Sloan Management Review's assessment is blunter still, estimating the cost of bad data at 15% to 25% of revenue for most companies, most of it absorbed invisibly as people correct errors and seek confirmation elsewhere. A consolidation is the one moment a group gets to reduce that figure rather than carry it forward at scale.
A migration that preserves every record and none of its context has moved the group's data without moving its memory.
Why does group reporting break even when every record arrives safely?
Group reporting is comparative by nature. A board pack that cannot show this quarter against the same quarter last year is a list of numbers, not a report. That comparison depends on history surviving in a form the new system can query, with the entity of origin attached to every row.
Take an illustrative group of three trading companies: a commercial installer, a maintenance business and a parts distributor, perhaps sixty people across sales and account management, three CRM instances bought in different years. Combined, say 41,000 contacts, 9,400 company records, and around 1,300 companies that appear in more than one instance. The migration proposal arrives with a line item for contacts, companies and open opportunities, and an explicit exclusion for closed opportunities older than 24 months, because they inflate the migration cost and nobody has asked for them.
That exclusion is the moment the group loses three years of win rates by entity, every piece of evidence about which customers buy from more than one company, and the only record of what the distributor's average deal size looked like before the price rise. The FD finds out in April, when the year-on-year comparison in the board pack stops at the cutover date. Reconstructing it afterwards means paying for a bespoke report against an archive nobody indexed, which is how the cost of custom CRM reports quietly becomes a recurring line in the budget. The fix is cheap at the planning stage and expensive at every other stage, which is a reliable signature of decisions that get skipped.
Who owns the customer once the instances are merged?
Deduplication is presented as a technical task and is almost never one. When two records for the same buying entity are merged, the merge picks a survivor, the survivor carries an owner, and that owner has a claim on the account and on whatever commission attaches to it. In the illustrative group above, of 1,300 overlapping company records perhaps 180 are genuinely the same buying entity at the same site, with two different account managers in two different companies who both believe they hold the relationship.
Nobody can resolve 180 of those arguments in a migration weekend. The sequence that works is to agree the ownership rule first, in the abstract, while it is still a policy question rather than a conversation about named individuals and their numbers. The same question in its steady state is covered in who owns the customer when two group companies sell to the same client, and the mechanics of what each brand can then see are set out in CRM permissions across group companies.
In practice, the thing that makes this hard is architectural rather than political. Most platforms are built to manage visibility within a single brand, and they do that imperfectly. Between brands, the available setting is usually binary: a user can see everything across the group, or nothing outside their own entity. A consolidation forced through that constraint produces one of two bad outcomes. Either the group opens the whole database to everyone and immediately regrets it on the first sensitive account, or it walls each entity off so completely that the group has paid for a single system that behaves exactly like the three it replaced. Fine-grained visibility control, within a brand and between brands, is a foundation rather than a configuration option, which is the argument running through multi-entity CRM architecture more generally.
What does UK data protection require when merging group CRM systems?
The Information Commissioner's Office is explicit that its data sharing code covers disclosure between controllers and does not cover movement of data within one organisation where the controller is the same. Where group companies pool data, the ICO's guidance is that the organisations must establish whether they are separate or joint controllers, and joint controllers are required under Article 26 of the UK GDPR to put a formal, transparent arrangement in place setting out who is responsible for what. The ICO's advice for smaller organisations also flags that a change in organisational structure, such as an acquisition or merger, needs particular care where the controller changes or an additional controller gains access.
There is a second, more useful point hiding in the compliance work. A consolidation is the only time a group has every record in front of it at once, which makes it the natural moment to apply storage limitation rather than defer it again. The ICO's records management guidance expects storage periods for personal data to be documented in a retention schedule, and warns that without one, information may be retained for longer than necessary (ICO, Retention). Migrating an eleven-year-old marketing list with no identifiable lawful basis into a shiny new group instance converts a dormant problem into a live one, and does it at the exact moment the group can least afford a distraction.
Should you migrate everything at once?
McKinsey's work on IT in mergers makes an argument that transfers cleanly to CRM consolidation inside a group: successful IT integrations deliver cost savings of 10 to 15 per cent, and 50 to 60 per cent of the initiatives intended to capture synergies are strongly related to IT, yet most IT issues are not fully addressed early. McKinsey's blunter observation is that swift integration of systems is worth more than a long debate about the relative merits of competing ones, and that it sometimes makes sense to leave a legacy system running where it is tied closely to a distinct customer base.
That gives a group three defensible options rather than one.
| Approach | What it costs | What it preserves | Where it hurts |
|---|---|---|---|
| Full migration of all history | Highest migration fee, longest mapping effort | Everything, if field mapping is done properly | Carries forward every data quality and retention problem the group already had |
| Live book migrated, closed history to a read-only archive | Moderate; archive storage is cheap | Open pipeline and recent comparatives; older history queryable but not in-system | Archive must be indexed and accessible, or it is a deletion with extra steps |
| Old instances kept live read-only for a fixed period | Duplicate licence cost during the overlap | Full fidelity, including audit trails | Two sources of truth for as long as it runs, which invites exactly the behaviour you are consolidating to end |
The second option is right more often than the first, and the deciding factor is whether the group can reliably query the archive when the board asks. An archive nobody can search is a polite way of discarding the history. The licence arithmetic behind the third option is the same arithmetic covered in the real cost of a CRM, and it tends to be cheaper than groups expect for a three-month overlap and far more expensive than they expect at twelve.
Figure
The decisions in a CRM consolidation, in the order they bind
- 01
Controller status per entity
Which legal entity controls which records, and whether entities are separate or joint controllers
Legal
- 02
Ownership rule for shared customers
Agreed in the abstract, before anyone sees whose name is on the record
Commercial
- 03
Permission model between brands
What each entity can see of the others, at record level rather than all or nothing
Architectural
- 04
History scope: live versus archive
How many years of closed opportunities move, and where the rest is queryable from
Reporting
- 05
Field mapping and dedupe rules
The step most projects start with, and the only one that is genuinely technical
Technical
McKinsey reports one pharmaceutical acquirer's integration team found that nine core-platform decisions accounted for around 70% of the deal's technology-related synergies.
Source: McKinsey, How to find and maximize digital value in any M&A deal
McKinsey's finding that a small set of core-platform decisions accounted for around 70 per cent of one acquirer's technology-related synergies is worth sitting with. The same concentration applies here. Four or five decisions, none of them about software, determine whether the group ends up with one system that behaves like a group or one system that behaves like three tenants sharing a database. Groups still weighing whether to merge at all will find the prior question handled in one CRM or one per company, and the reporting consequences in group reporting across multiple entities.
Frequently Asked Questions
How long does it take to consolidate multiple CRM systems into one?
Timelines vary with the number of entities, the volume of custom fields and the state of the underlying data. McKinsey's research on merger integration notes that acquirers with a prepared platform and a clear migration strategy can move data from an acquired business in under six months, and that speed of integration tends to be worth more than extended debate about which system is technically superior.
Does consolidating CRM systems mean deleting the old instances?
No. A common pattern is to migrate the live book and recent history into the new system while retaining older closed records in a searchable archive, or keeping the legacy instances in read-only mode for a defined overlap period. Any retention decision should be documented in a retention schedule, which the ICO expects to cover storage periods for all personal data.
Do group companies need a data sharing agreement to move CRM data into one system?
Where separate legal entities in a group are separate controllers, the ICO treats the movement of personal data between them as data sharing, and considers a data sharing agreement good practice for separate controllers. Where entities are joint controllers, Article 26 of the UK GDPR requires a formal, transparent arrangement setting out each party's responsibilities.
What causes most of the history loss in a CRM migration?
Three things account for the majority: closed opportunities excluded from scope to reduce migration cost, custom fields with no equivalent in the destination schema being dropped during mapping, and pipeline stage labels being normalised across entities without preserving the original value. All three are decisions made during planning rather than failures of the migration itself.
Should duplicate records be merged automatically during consolidation?
Automated matching is useful for identifying candidates, but the merge itself assigns an owner to the surviving record, which has commercial and compensation consequences. Groups generally benefit from agreeing an ownership rule before the matching runs, so the system applies a policy rather than creating several hundred individual disputes at cutover.