M&A integration — four data problems pretending to be one deal.

The four data problems hidden in every deal.

"Integrate the data" is a 3-year program disguised as a one-line slide. The interview-grade decomposition: every M&A has four orthogonal data problems, each with its own pattern, its own team, and its own failure mode. Conflate them and you ship a broken migration; separate them and the work parallelizes.

The four buckets

Why "just migrate everything to one system" doesn't work

The naive 3-month plan: pick the acquirer's stack, ETL the target's data over, sunset the target's systems. It always slips. Three reasons:

1. The acquired product keeps shipping. You can't freeze their database for 90 days while you migrate; their customers expect the product to keep working. Schema needs to support both apps during the convergence window.
2. Customer IDs aren't the same shape. Their B2B account model has a hierarchy; yours is flat. Their "user" is your "contact". Merging tables ≠ merging meaning.
3. Compliance is sticky. Acquired company's customers signed THEIR privacy notice. Moving their data into your systems may require re-consent in EU/CA. Engineering can't paper over this.

Entity resolution — golden records across two CRMs.

The day-one question after any acquisition: "how many overlapping customers do we have?". Marketing thinks 30%. Sales thinks 60%. Nobody can prove either number until you build an identity graph that resolves their Acme Corp and your Acme Corp into one entity — across two CRMs with different field names, formats, and hierarchies.

The matching playbook — strict rules first, fuzzy rules second

You never decide "these two rows are the same customer" using one rule. You run an ordered list of rules from strict to permissive. The first rule that fires wins. Same idea as airport security: passport check first (definite ID), then bag scan, then pat-down. The strict rules auto-merge with high confidence; the fuzzy rules send candidates to a human analyst.

Some industry references call this the "match-key cascade" or "match-tier cascade" — same thing, just academic-sounding names for an ordered rule list.

The golden record schema

The golden_customer table is the unified entity. Source systems keep their own customer tables; the golden record references both via a crosswalk:

-- The golden record (unified entity, mastered)
CREATE TABLE golden_customer (
    golden_customer_id  UUID PRIMARY KEY,
    canonical_name      TEXT NOT NULL,
    canonical_domain    TEXT,
    duns_number         TEXT,
    industry            TEXT,
    country             TEXT,
    first_seen_at       TIMESTAMP NOT NULL,
    -- Lineage: which source(s) contributed to this golden record?
    sources             TEXT[]  -- e.g. ['acquirer_crm', 'target_crm']
);

-- The crosswalk: source-system IDs ↔ golden ID
-- This is what every downstream join uses to "see one customer" across the data.
CREATE TABLE customer_xref (
    source_system       TEXT NOT NULL,    -- 'acquirer_crm' | 'target_crm' | …
    source_customer_id  TEXT NOT NULL,
    golden_customer_id  UUID NOT NULL REFERENCES golden_customer,
    match_rule          INT  NOT NULL,    -- 1-5, which playbook rule fired
    match_confidence    NUMERIC NOT NULL, -- 0.0 - 1.0
    matched_at          TIMESTAMP NOT NULL,
    matched_by          TEXT NOT NULL,    -- 'auto-rule-tier-1' | 'mdm-analyst-alice'
    superseded_by       UUID,             -- for un-merge / re-merge audit
    PRIMARY KEY (source_system, source_customer_id)
);

The un-merge — the part everyone forgets

Two months after launch, an MDM analyst realizes "Acme Corp Holding" and "Acme Corporation" were merged but they're actually parent/subsidiary, not duplicates. You need to un-merge without losing referential integrity for the downstream pipelines that already consumed the wrong golden ID.

The superseded_by column + append-only crosswalk + golden record SCD2 is the pattern. Never DELETE a golden record; retire it, point the affected source IDs at a new golden ID, log who/when, and emit a CDC event downstream so fact tables can re-attribute.

Identity for B2B vs B2C

B2B (Salesforce-Slack, Cisco-Splunk): match on account (the company), not user. Acquired company's "Splunk Cloud users at Acme" should resolve to acquirer's "Cisco Meraki account: Acme Inc.". User-level identity is downstream of account identity.

B2C (Microsoft-Activision): match on user (often hashed email + console / platform ID). The merge target is the gamer, not their household. Identity graph here is much messier — same player on Xbox Live, Battle.net, Steam, and PlayStation Network is one person with four federated IDs.

Schema unification — the strangler pattern, dual-write, cutover.

Both apps keep shipping. You can't freeze either database. The merger schema needs to converge over months without a flag day. The pattern is the strangler fig (Martin Fowler, 2004), adapted for data:

1. Stand up the unified schema alongside the two source schemas. Don't touch source apps yet.
2. Dual-write every change: source-app writes go to source DB and to a CDC stream that lands in the unified schema with a translation layer.
3. Backfill: historical rows replayed into the unified schema. Run reconciliation queries comparing source and unified.
4. Cutover, one entity at a time: switch the source app to read from the unified schema (still dual-write). Re-validate.
5. Stop dual-write: source app reads and writes only to the unified schema. Sunset the old table.

The dual-write architecture

The reconciliation query — drift detection

Dual-write only earns trust if you can prove convergence. Run this every hour during the cutover window:

WITH source_counts AS (
  SELECT 'acquirer_crm' AS src, COUNT(*) AS n, MAX(updated_at) AS last_change
  FROM acquirer_crm.customers
  UNION ALL
  SELECT 'target_crm', COUNT(*), MAX(updated_at)
  FROM target_crm.tenants
),
unified_counts AS (
  SELECT source_system AS src, COUNT(*) AS n,
         MAX(ingested_at) AS last_ingest,
         COUNT(*) FILTER (WHERE ingest_status = 'rejected') AS rejected
  FROM unified.customer_ingest_log
  GROUP BY source_system
)
SELECT s.src,
       s.n AS source_rows, u.n AS unified_rows,
       s.n - u.n AS drift,
       100.0 * ABS(s.n - u.n) / NULLIF(s.n, 0) AS drift_pct,
       u.rejected,
       EXTRACT(EPOCH FROM (s.last_change - u.last_ingest)) AS lag_seconds
FROM source_counts s LEFT JOIN unified_counts u USING (src)
ORDER BY src;

Drift > 0.1% pages the on-call. Lag > 5 minutes pages the on-call. The team that owns this query owns the cutover; nobody flips the read switch until both have been green for 72 consecutive hours.

Warehouse consolidation — Snowflake / Databricks / BigQuery merger.

The CFO sees a $2.4M/yr Snowflake bill plus the acquired team's $1.1M/yr Databricks bill. "Pick one." This is the easiest question to ask and the hardest to execute. Three paths, none of them free:

The three strategies

The "Day 90 reporting" reality

The board wants a combined revenue dashboard 90 days in. Big-bang isn't done in 90 days. So every real M&A uses share-and-bridge for the first 6 months, then commits to one of the other two strategies once governance + lineage + access have been sorted.

-- Snowflake cross-account share (acquirer → target reads acquirer data)
CREATE SHARE acq_to_target;
GRANT USAGE ON DATABASE prod_dw TO SHARE acq_to_target;
GRANT USAGE ON SCHEMA prod_dw.combined_metrics TO SHARE acq_to_target;
GRANT SELECT ON ALL TABLES IN SCHEMA prod_dw.combined_metrics TO SHARE acq_to_target;
ALTER SHARE acq_to_target ADD ACCOUNTS = ('TARGET_ACCOUNT_LOCATOR');

-- On the target side, mount as read-only DB
CREATE DATABASE from_acquirer FROM SHARE acquirer.acq_to_target;
SELECT * FROM from_acquirer.combined_metrics.fct_revenue_daily WHERE biz_date >= '2025-01-01';

Lineage rebuild is the silent cost

Both companies had their own column-level lineage (Atlan, Monte Carlo, Datafold, dbt docs). The merger means none of it is correct any more. The unified warehouse needs cross-source lineage from day one:

• Source-system → unified-schema table-level lineage (which raw tables produced which unified table)
• Translation layer → column-level lineage with transform documented (target.tenant_uuid → unified.account_id via customer_xref)
• Downstream dbt model lineage (which BI dashboard reads from which unified table)

Without this, the first ad-hoc CFO question — "show me ARR but exclude double-counted overlapping customers" — takes 2 weeks because nobody knows which models touch which tables.

Multi-org metrics — when their DAU isn't your DAU.

The board deck has a "combined DAU" number on slide 3. It's wrong, but nobody will notice for two quarters. Reasons it's wrong:

The dim_metric_definition table

Don't bake definitions into SQL. Bake them into a versioned dim that the BI layer references:

CREATE TABLE dim_metric_definition (
    metric_id           TEXT NOT NULL,            -- 'dau'
    definition_version  INT  NOT NULL,            -- 1, 2, 3
    org_scope           TEXT NOT NULL,            -- 'acquirer' | 'target' | 'combined'
    window_unit         TEXT NOT NULL,            -- 'hour' | 'day' | 'week'
    window_size         INT  NOT NULL,            -- 24, 7, etc.
    dedup_grain         TEXT NOT NULL,            -- 'user' | 'user-day' | 'session'
    fiscal_calendar     TEXT NOT NULL,            -- 'calendar' | '445'
    currency_policy     TEXT NOT NULL,            -- 'lock-at-txn' | 'lock-at-month-end'
    effective_from      DATE NOT NULL,
    effective_to        DATE,                     -- NULL = current
    PRIMARY KEY (metric_id, definition_version)
);

Every dashboard tile cites a (metric_id, definition_version) tuple in its config. The "combined DAU on the board deck" can be definitively traced to definition_version=3 with org_scope='combined', window_size=1, dedup_grain='user-day', and the SQL is auto-generated from that row.

Four deals — the data side of the press release.

The 90-second articulation script.

When the interviewer says "your company just acquired a $20B SaaS — walk me through the data integration", this is the structure that wins:

1. Name the four problems first (15 sec). "Every M&A has four orthogonal data problems: entity resolution, schema unification, warehouse consolidation, multi-org metrics. They have different owners and different failure modes. Let me ask which one matters most for day 90 before I pick where to start."
2. Pick entity resolution as the foundation (15 sec). "If I had to start somewhere, it's entity resolution — because every other layer reads from the golden record. Strict rules first (same domain + DUNS → auto-merge), fuzzy rules second (similar name + same country → human reviews), unmatched rows stay distinct. Append-only crosswalk with superseded_by for un-merge."
3. Address schema unification (20 sec). "Strangler pattern: both apps keep writing to their source DBs, CDC streams to a unified schema via a translation layer, daily drift reconciliation between source counts and unified counts. Cutover one entity at a time. Plan for 6-18 months."
4. Address warehouse consolidation (20 sec). "Three options: big-bang migration if stacks are strategically incompatible, federated query if they complement, share-and-bridge as the day-90 unblocker before you commit. Tag-based cost attribution so the CFO can see the bill split."
5. Address multi-org metrics (15 sec). "Don't bake definitions into SQL. Materialize dim_metric_definition with org_scope, window, dedup_grain, fiscal calendar, currency policy as versioned rows. Every dashboard cites a (metric_id, definition_version)."
6. Close on the trap (5 sec). "The mistake teams make is solving these in parallel before naming them — that creates cross-team blocking and shipped-but-wrong dashboards. Naming the four lets you sequence."