The deal closed on Friday. On Monday, you have two Salesforce instances, two HubSpot accounts, or one of each — and a mandate from leadership to “integrate the customer data” within 90 days.

Both systems contain tens of thousands of customer records. Some customers exist in both. Some exist in only one. For the customers that appear in both, the data rarely agrees: different addresses, different contact names, different revenue figures, different account statuses. One system says Acme Corp is a $2M account. The other says Acme Corporation is a $1.4M account. Are those the same company? If so, which revenue number is right?

This is the post-merger customer data problem. It’s not a technology problem first — it’s a matching problem, then a conflict resolution problem, then a technology problem. Get the matching wrong and everything downstream is built on bad data.

The post-merger data problem: two CRMs, one truth

Every company accumulates customer data in its own way. Sales teams enter records with their own naming conventions. Data imports from trade shows, partner lists, and marketing platforms each introduce their own formatting. Over years of operation, each CRM develops its own dialect for representing the same real-world entities.

When two companies merge, you’re not just combining two databases. You’re combining two dialects, two sets of conventions, two histories of data entry decisions made by people who never coordinated with each other.

Company A’s CRM stores International Business Machines with a billing address in Armonk, NY. Company B’s CRM stores IBM Corp. with a billing address at a regional office in Austin, TX. Same company. Different representations. Different addresses that are both technically correct.

Multiply that by 30,000 customer records in each system, and the scope of the problem becomes clear. You can’t eyeball it. You can’t VLOOKUP it. You need systematic matching that handles name variations, address differences, and the fundamental ambiguity of real-world business entities.

The same customer across two CRM systems
Field Company A's CRM Company B's CRM Conflict type
Company name Acme Industrial Solutions, LLC Acme Industrial Solutions Minor (suffix)
Primary contact Sarah Chen, VP Procurement David Park, Director of Purchasing Different person
Phone (312) 555-0187 312.555.0187 Format only
Address 200 W. Adams St, Ste 1400, Chicago IL 60606 200 West Adams Street, Floor 14, Chicago IL Abbreviation + detail
Annual revenue $2,100,000 $1,430,000 Different fiscal periods
Account status Enterprise Mid-Market Different tier definitions
Last activity 2025-09-15 2025-10-02 Different interaction

Same customer, two representations. Name and phone match with normalization. Contact, revenue, and tier require human judgment.

Look at this record pair. A naive exact match on company name would fail because of the trailing LLC. A match on phone number would succeed — but only after normalizing formatting. The contact name is entirely different because each company had a different relationship within the same account. The revenue numbers disagree because they reflect different contract scopes or fiscal year boundaries. The account tier labels mean different things in each system’s classification scheme.

None of these conflicts have an obvious automated resolution. But identifying that these two records refer to the same customer is the critical first step. Until you know which records overlap, you can’t even begin to resolve the conflicts.

Understanding the overlap: how much customer duplication to expect

Before diving into the matching process, it helps to calibrate your expectations. The degree of customer overlap between two merging companies depends on several factors.

Market overlap. Two companies selling the same product category to the same geography will share more customers than two companies with complementary offerings in different regions. A merger of two regional insurance brokers might find 35% customer overlap. A merger of a hardware manufacturer with a software company serving the same industry might find 20%.

Customer type. B2B overlap is typically higher than B2C because there are fewer businesses than consumers in any given market. Two enterprise SaaS companies in the same vertical might share 25-40% of their named accounts. Two consumer brands with national distribution might share less than 5% of identifiable customers.

Data quality. Overlap is a measurement problem as much as a reality. If Company A’s CRM has 40,000 records but 15% are duplicates, defunct companies, or junk data, the real customer base is closer to 34,000. Poor data quality inflates apparent overlap (the same customer appears multiple times) and deflates it (legitimate customers aren’t recognized because their records are incomplete).

Typical customer overlap rates by merger type
Same product, same geography Direct competitors
38%
Same product, different geography Regional expansion
14%
Complementary products, same customers Cross-sell acquisition
27%
Adjacent verticals Market expansion
9%
Unrelated businesses (conglomerate) Portfolio diversification
3%

Median overlap rates based on post-merger integration analyses across mid-market and enterprise M&A.

Knowing your expected overlap range informs your matching strategy. High-overlap mergers (30%+) require careful deduplication and conflict resolution for a large portion of the combined database. Low-overlap mergers (under 10%) are primarily about combining two mostly distinct datasets, with deduplication as a smaller secondary concern.

Run the matching analysis early — ideally during due diligence, before the deal closes. The overlap percentage directly impacts integration cost estimates, CRM licensing decisions, and sales territory planning. Discovering that 40% of the acquired company’s “new” customers are already yours changes the value calculation.

The matching approach: multi-field comparison across both databases

Customer record matching between two CRMs is a multi-field problem. No single field is reliable enough on its own.

Company name is the most intuitive field to match on, but it’s the least reliable. Acme Inc., Acme, Inc., ACME Industries, Acme Industrial Solutions LLC — these might be the same company or four different ones. Legal suffixes, abbreviations, and DBA names create enormous ambiguity in name-only matching.

Domain name or email domain is one of the strongest signals for B2B matching. If both CRMs have contacts with @acme.com email addresses, those records almost certainly belong to the same company. Domain matching is robust to name variations, abbreviations, and rebranding.

Phone number is strong after normalization. Strip formatting, country codes, and extensions. If the underlying digits match, you have a strong signal. But businesses often have multiple phone numbers, and the number in CRM A might be the main line while CRM B has a direct dial.

Address requires normalization before comparison. Standardize abbreviations (St. vs Street), suite/floor notation, and ZIP code formats. Even after normalization, businesses with multiple locations will have different addresses in different systems — both legitimate.

Tax ID or DUNS number, when available, provides a near-definitive match. But these fields are often empty in CRM data, especially for smaller accounts.

The practical approach is to score across multiple fields with different weights:

  • Domain match: high confidence (0.9+ if domains match)
  • Phone match (normalized): high confidence
  • Name match (fuzzy, 0.85+ threshold): medium confidence
  • Address match (normalized): supporting evidence
  • Contact name overlap: supporting evidence

A match on domain plus fuzzy name match is almost certainly correct. A fuzzy name match alone at 0.86 with no corroborating fields needs manual review. The multi-field approach lets you triage automatically: high-confidence matches are approved, low-confidence candidates go to a review queue, and clear non-matches are excluded.

Handling entity variations: subsidiaries, DBAs, and parent/child relationships

Real-world business entities are messier than flat CRM records suggest. A single “customer” might appear as multiple distinct records that shouldn’t be merged — and that distinction matters.

Subsidiaries. Company A sells to Global Manufacturing Inc. Company B sells to Global Mfg West Coast Division. These are related but not identical. Merging them into one record would obscure the fact that you have relationships with different parts of the organization. The correct action is to link them in a hierarchy, not merge them.

DBAs and trade names. Robert Chen does business as Chen's Auto Repair, which is registered as RC Automotive LLC. Three names, one entity. Your CRM might have any combination of these across the two systems.

Rebranded entities. Company B acquired a customer when they were Anderson & Sons Plumbing. They rebranded to Anderson Plumbing Group two years ago. Company A onboarded them under the new name. The records look like different companies unless you have historical data or a shared identifier.

Franchises. McDonald's #12847 and McDonald's Store 12847 - Oak Park, IL are the same location. But McDonald's Corporate is a different entity entirely. Matching must distinguish location-level records from corporate-level records.

Entity variation types and recommended matching actions
Variation type Example Correct action Common mistake
Direct duplicate Acme Inc. / ACME, Inc. Merge into golden record Keeping both as separate accounts
Subsidiary Global Mfg / Global Mfg West Division Link in hierarchy, keep separate Merging into single record
DBA / trade name RC Automotive LLC / Chen's Auto Repair Merge, retain aliases Treating as two customers
Rebrand Anderson & Sons / Anderson Plumbing Group Merge, update to current name Missing the match entirely
Franchise location McDonald's #12847 / McDonald's Corporate Keep separate, link to parent Merging location into corporate

The correct action depends on your CRM's hierarchy capabilities and your organization's account structure.

The matching phase should identify all of these relationships. But the action taken should differ by type. Direct duplicates get merged. Subsidiaries get linked. DBAs get consolidated. The matching tool tells you which records are related; your data governance rules tell you what to do about it.

In practice, this means running the matching at multiple levels. First, match at the entity level to find direct duplicates (high threshold, strong field agreement). Then, run a second pass at a lower threshold to identify potential parent-child and subsidiary relationships. Tag each match with its relationship type so the consolidation team knows how to process it.

Conflict resolution: which system’s data wins when records disagree

Once you’ve identified matching records, you face the harder question: when the two records disagree, which version do you keep?

This is where survivorship rules come in. Survivorship rules are pre-defined policies that determine which system’s data takes precedence for each field. Without them, every conflict becomes an ad-hoc decision — and with thousands of conflicting records, ad-hoc doesn’t scale.

Common survivorship strategies:

Most recent wins. For fields that change over time — address, phone number, contact name — take the value with the most recent update timestamp. This assumes the newer data is more accurate, which is usually true for contact information.

Most complete wins. For fields where one system has data and the other has NULL or a placeholder, take the non-empty value. If Company A has a full address and Company B has just a city and state, the full address wins.

Source system authority. Designate one system as authoritative for specific field categories. The acquiring company’s CRM might be authoritative for account tier and sales rep assignment, while the acquired company’s CRM is authoritative for contract terms and pricing because they had the direct relationship.

Largest value wins. For revenue and contract size, the larger value is often more accurate because it reflects the most recent or most complete view of the relationship. But this rule needs human oversight — the larger value might be inflated or duplicated.

Manual review. For high-value accounts or cases where automated rules can’t determine a winner, route the conflict to a data steward. Limit this to the top 5-10% of records by value to keep the manual workload manageable.

The key is to define survivorship rules before starting consolidation. Document them, get stakeholder agreement, and apply them consistently. Changing rules mid-process introduces inconsistency that’s harder to detect than the original conflicts.

Building the golden record: merged, enriched, and deduplicated

The golden record is the end product of consolidation: a single, authoritative customer record that combines the best data from both source systems.

Building golden records is a multi-step process that follows directly from matching and conflict resolution:

Step 1: Start with the matched pair. For each pair of records identified as duplicates, create a new record that will become the golden record.

Step 2: Apply survivorship rules field by field. For each field, evaluate which source has the better value based on your predefined rules. Populate the golden record with the winning values.

Step 3: Merge transaction histories. The golden record should aggregate activity from both systems — total purchases, all support tickets, complete interaction history. This is where the true value of consolidation appears: for the first time, you see the full relationship with this customer, not just one company’s slice of it.

Step 4: Retain source identifiers. Keep both system’s original IDs on the golden record as cross-reference fields. When someone in the acquiring company references an old account number, you need to be able to look it up.

Step 5: Flag and log every decision. For each field where a conflict was resolved, log what the original values were, which rule was applied, and what the outcome was. This audit trail is essential for explaining decisions later and for rolling back if a rule turns out to be wrong.

Step 6: Handle the singletons. Records that exist in only one system (no match in the other) are imported directly into the consolidated database. No conflict resolution needed, but they should still be validated for data quality — they may have the same issues (duplicates, stale data) that existed in their source system.

For the records that weren’t duplicates but are related (subsidiaries, parent-child), create the hierarchy links in the target CRM. Populate the parent account field, set up the account hierarchy, and ensure rollup fields (total revenue, number of locations) calculate correctly across the hierarchy.

The golden record isn’t a one-time creation. As the combined sales team starts working in the new system, they’ll discover records that were miscategorized during consolidation — a subsidiary that should have been merged, a duplicate that was missed, a conflict that was resolved incorrectly. Build a feedback process for the first 90 days post-consolidation to catch and correct these issues.

Match Data Studio simplifies the most labor-intensive part of post-merger consolidation: matching customer records across two systems. Upload both CRM exports, configure multi-field matching with fuzzy tolerance for name and address variations, and get a clear picture of your overlap — with confidence scores that tell you which matches are certain and which need human review. Start consolidating your customer data —>

Keep reading