Post-acquisition data integration

The job is arbitration, not migration

A migration has one authority and one destination. A post-close integration has two authorities that both believe they are correct about the same customer, the same part number and the same dollar of revenue. Nothing gets easier until someone decides, field by field, which system wins and why. That decision is the work. The mappings, the pipelines and the cutover weekend are only how it gets carried out.

This is why integration programs slip in a shape that repeats across industries. The plan assumes a target schema exists and the sources map into it. What is true is that the two companies modeled the world differently on purpose. One counts a customer at the billing account, the other at the parent legal entity. One closes a period on the last calendar day, the other on the last Friday. Neither is a defect. Each was reasonable inside one company and is now a conflict inside two.

A useful test in the first week: pick three numbers the combined leadership will be asked for in the first quarter, such as revenue by customer, headcount by function and open orders by product line. Ask each side to produce them from its own systems, on the same as-of date, with no coordination. The gap between the two answers is the real scope. Everything after that is scheduling.

Read that as an ordering, not as percentages of a budget. The bottom row is worth arguing with: moving data between two systems is a solved problem, and still the line item most plans size first and largest.

Before close, the wall is the point

Under the Hart-Scott-Rodino premerger notification provisions at 15 U.S.C. 18a, a reportable transaction gets filed with the antitrust agencies and the parties wait before closing. The statute sets that waiting period at thirty days after receipt of the notification for most acquisitions and fifteen days for a cash tender offer, extended when the agencies issue a request for additional information. The size-of-transaction test sits in the statute at a base figure republished each year under a gross national product adjustment formula, so the operative figure is whichever one the agencies have published for the current year.

Two companies that are still competitors until closing cannot behave as one before then. Integration teams usually hear this as "the clean team rule" with no reason attached, which makes it feel like theater. It is not. Coordinating on price, customers or output before closing is an antitrust problem in its own right, separate from the merger review, and it does not become retroactively fine because the deal later closed.

What that means for a data team is specific. Raw customer records, price files, live pipeline and unit-level cost detail from the other side stay away from anyone carrying commercial responsibility on this side. A designated clean team with no pricing or go-to-market role, working with outside counsel, can see more than the deal team can. Counsel draws that line, not the integration lead.

The good news is that the artifacts driving the integration design are mostly metadata, and metadata is the easiest category to get cleared. Table and column inventories. Row counts, null rates, cardinality and format profiles. Referential integrity checks. Retention schedules. Systems of record and their owners. A team that spends the waiting period assembling that inventory reaches Day 1 with a design. A team that waits for close spends two months on discovery it could have finished already.

Overlap between the two customer bases is the number everyone wants early, and the one that cannot be computed by exchanging lists. The usual route is a third party under counsel's direction comparing hashed or tokenized identifiers and returning aggregate counts only. Ask for that structure early: the answer changes the integration plan more than almost anything else in diligence.

Four restriction classes travel with the records

Data does not arrive in the new environment as neutral bytes. It carries whatever obligations attached before the deal, and those mostly survive a change in ownership. So the target architecture gets designed around the most restricted class present, not the average one.

Class	Where the authority sits	What it constrains after close
Protected health information	45 CFR 164.501 includes within health care operations "the sale, transfer, merger, or consolidation of all or part of the covered entity with another covered entity, or an entity that following such activity will become a covered entity and due diligence related to such activity"	The transaction itself has a lane. Every processor that touches the data in the new architecture still needs a business associate agreement in place first.
Consumer personal information, US state law	Cal. Civ. Code 1798.140(ad)(2)(C) carves an asset transfer in a merger or acquisition out of "sell," provided the information is "used or shared consistently with this title"	The buyer inherits the promises made at collection. A change of use materially inconsistent with those promises requires prior notice to the consumer.
Personal data under GDPR	Article 5(1)(b) purpose limitation, 5(1)(c) minimisation, 5(2) accountability, and the Article 6(4) compatibility factors	Combining two customer bases is further processing. The test weighs the link between purposes, the collection context, the nature of the data, consequences for data subjects, and safeguards such as encryption or pseudonymisation.
Controlled unclassified information	DFARS 252.204-7012, which requires NIST SP 800-171 (Revision 3, final May 2024) and defines "rapidly report" as within 72 hours of discovery of a cyber incident	Controls follow the data into the new environment. Paragraph (m)(1) flows the clause down to subcontractors without alteration, including whoever runs the migration.
Export-controlled technical data	22 CFR 122.4 for registrant change reporting, with the underlying technical data controls separate from it	Merging repositories can place controlled technical data in front of people not authorized to see it. Access control gets designed before the merge, not repaired after.
Federal contract records	FAR 4.703: records available for three years after final payment, or the periods at 4.705 through 4.705-3, whichever expires first	Retention obligations outlive the deal. Copying a source system forward does not by itself earn the right to switch the source off.

The sequence that fails is the common one: build the combined warehouse, then ask privacy and security to bless it. The sequence that works tags the restricted classes during the metadata inventory, decides a containment model for each, and designs the target so a record's controls arrive before the record does.

A federal contract inside the target is its own transaction

If either estate holds government contracts, the corporate transaction has a parallel one running on the contracting officer's calendar. FAR subpart 42.12 governs it. A novation agreement recognizes a successor in interest when contractor assets transfer through an asset sale, a merger or an incorporation. FAR 42.1204(b) draws the useful line: a change in the ownership of a contractor as a result of a stock purchase, with no legal change in the contracting party, and where that party remains in control of the assets and is performing the contract, does not require a novation.

When one is required, the transferee's package is substantial. It includes three signed copies of the proposed agreement, the purchase or sale instrument, a list of every affected contract with numbers, values and unpaid balances, evidence that the transferee can perform, authenticated instruments of transfer, board resolutions and stockholder minutes, an opinion of counsel that the transfer was properly effected, audited balance sheets before and after the transfer, security clearance documentation and surety consent on bonded contracts.

Two lines in that list belong to the data team. The contract list with unpaid balances comes out of the target's financial systems and has to be reproducible months later, so the system that produced it stays queryable until the novation closes. The balance sheets before and after the transfer are a second reason to preserve the pre-close books rather than transform them in place.

Export registration runs its own clock. Under 22 CFR 122.4, a registrant gives written notification within five days of specified changes, including a change in ownership or control and the establishment, acquisition or divestment of a US or foreign subsidiary, with amended registration material following within sixty days. A sale or transfer to a foreign person of ownership or control requires notice by registered mail at least sixty days in advance.

Classified work adds another. Under 32 CFR 117.8(c)(7), a cleared contractor reports a change of ownership or control including stock transfers that affect control, a change of operating name or address of the entity or of any location determined eligible for access to classified information, any material change to previously reported foreign ownership, control or influence information on an updated SF 328, and entry into discussions or agreements that may reasonably lead to effective ownership or control by a foreign interest.

None of those filings are the integration lead's to sign, and all of them rest on inventories the integration lead is the only person positioned to produce. A report on the address of "any of its locations" is accurate only if somebody can enumerate every location.

The inventory that precedes the first mapping

Mapping written before the inventory exists gets rewritten. The list below is what a target design can be built on, and most of it can be assembled during the waiting period because it is metadata rather than records.

• Systems of record, named with an owner. Not procurement's application list. The systems others copy from, and the human who decides when each is wrong.
• Authoritative field ownership. Which system owns which attribute today, including where the honest answer is "both, inconsistently."
• Retention schedules and legal holds. A hold survives the acquisition and can stop a decommission cold.
• Third-party data licenses and their assignment clauses. Purchased datasets, market feeds and enrichment services often do not transfer to an affiliate without consent, and the seat count almost never does.
• Location of regulated categories. Where health information, consumer personal data, controlled unclassified information and export-controlled technical data physically live, backups and analytics copies included.
• Encryption and key custody. Who holds the keys, whether they are escrowed, and what happens the day the seller's identity provider stops issuing tokens.
• Interface inventory. Every scheduled job, file drop, API integration and manual spreadsheet that moves data between systems. The spreadsheets are load-bearing.
• Reporting dependency map. The reports leadership notices within one cycle if they break, traced to the tables that feed them.
• Key quality per shared entity. Row counts, duplicate rates and null rates on the identifiers you plan to match on, measured before anyone promises a match rate.

Entity resolution is most of the work

Two customer masters, two vendor masters, two product catalogs and two employee rosters become one of each. This consumes the engineering calendar, and loose method here produces numbers nobody can defend later.

Blocking comes first. Comparing every record on one side to every record on the other is quadratic and not feasible at any interesting scale. Blocking keys cut the candidate set down to pairs worth scoring: normalized name prefix plus postal code, email domain, tax identifier, registered entity number. Blocking recall is its own measurable quantity, and a pair that never enters a block can never be matched however good the scorer is.

Deterministic rules run before probabilistic scoring. Exact agreement on a strong identifier settles a match without a model. Everything left over goes to a scored comparison across several fields, where each field earns weight from how often it agrees among true matches versus how often it agrees by chance. Names are weak, addresses moderate, national identifiers strong, and a rule set that treats them as equal will merge two different companies that share a common name.

"We matched 87 percent" is not a result. It becomes one when someone states the denominator and the error rate beside it. The two error types are not symmetric. A false merge folds two real customers into one record and corrupts revenue history, credit exposure and contact data in a way that is hard to unwind, because the evidence they were separate has been overwritten. A false split leaves a duplicate a human can find later. Set thresholds to favor false splits and staff a review queue for the band between.

Measure on a labeled sample. Draw a few hundred candidate pairs stratified by score band, have two people label them independently, adjudicate the disagreements, and report precision and recall per band. That is about a day of work, and it puts the threshold where the evidence says rather than where the tool defaulted.

Survivorship is decided per field, not per record. The best mailing address may come from one system, the best payment terms from another and the best industry classification from a third. Write the rule for each field with a stated reason, and store the source system alongside each surviving value. That lineage column is what lets someone reverse a bad survivorship decision six months later without re-running the whole exercise.

The golden record is a process, not a table. Both sources keep transacting until they are retired, so resolution jobs keep running and the review queue keeps filling. Treating the master as a one-time build is how a company ends up with a merged customer table that was accurate on one Saturday.

Reconciliation is the deliverable

The load is not the milestone. The reconciliation is. For each domain, agree in advance on the short list of numbers that must be equal on both sides at the same as-of timestamp: active customers, open receivables, open orders, inventory units by location, headcount by legal entity. Freeze the timestamp, run both sides, publish the difference, and explain every line of it.

A difference you can explain is a healthy result. One nobody can explain means the mapping is wrong somewhere that has not been found, and shipping past it converts a data problem into an audit finding. Most explanations turn out to be the definitional conflicts from the first week, now quantified.

Then dual-run. Keep both systems producing the same figures for a defined number of cycles before the source is switched off. How many is a business decision, and for anything feeding a monthly close two or three clean cycles is the usual bar. The signed reconciliation from the final cycle is what finance, audit and the acquired leadership use to agree the integration is real.

Three consolidation patterns, chosen on purpose

Most programs pick one of these by accident, through whoever moves first. Picking deliberately, and writing down why, beats any tooling decision made the same week.

Pattern	When it is right	What it costs
Absorb Retire the acquired systems, move the data into the acquirer's platform	The acquirer's platform genuinely covers the acquired processes, and that business is materially smaller or operationally similar	Lowest run cost. Highest change burden on acquired teams, and it quietly discards model detail they may have needed
Coexist Both systems keep running; integrate through shared keys and a semantic layer above them	Contractual, regulatory or clearance reasons the systems cannot merge yet, or the thesis needs combined reporting rather than one operational stack	Fastest route to combined reporting. Becomes permanent debt when no retirement date is set, which is how a company acquires its third general ledger
Rebuild Stand up a new target and move both estates into it	Both systems are at end of life and neither model fits the combined business	Longest calendar, and the only pattern that fixes both companies' legacy problems. Fails when it expands into an unbounded transformation program

Coexist is the honest answer more often than integration plans admit, particularly where a cleared facility, a regulated workload or an unassignable license makes a merge impossible in year one. It is also the pattern that must carry a written retirement date and an owner: a temporary federation with no end date is a permanent one nobody approved.

Sequencing that keeps the business running

Durations move a long way between deals; the ordering does not. Reference data before transactions, transactions before analytics, and nothing decommissioned until something has reconciled.

Identity and entitlements are the long pole

Two directories, two permission models, two sets of groups whose names sound similar and mean different things. Merging tenants is mechanical and well documented. Merging entitlements is neither, and it is where the schedule quietly goes.

The failure pattern is predictable. To unblock the business, someone grants broad access temporarily while the role mapping gets worked out, and the temporary grant outlives the person who approved it. That is the access an auditor asks about later, and the same access that can put export-controlled technical data or health information in front of people not authorized for it. Remediation costs more than the mapping would have.

The order that works: inventory the entitlements actually exercised, from access logs rather than group membership, because membership overstates real usage by a wide margin. Map roles, not individual grants. Then cut identity over before the data it protects. A record that lands ahead of its access controls was, for some measurable window, unprotected.

The transition services agreement is a clock

In a carve-out, the seller keeps operating some systems for the buyer for a defined period under a transition services agreement. It is a priced schedule with an end date, and treating it as a safety net produces two familiar outcomes. The buyer reads the TSA period as slack and starts late, then finds the exit criteria require a working replacement rather than a plan for one. Or the schedule was drafted without anyone tracing which systems the data depends on, so a service the buyer needs is missing and gets bought as an amendment at the seller's convenience.

Read the TSA schedule line by line against the system inventory in the first month, not the last. Price the extension before you need it, assuming at least one service runs long. Extensions are usually available and usually expensive, and the negotiating position is better while time remains on the original clock.

What done looks like

Done is not "the data has been loaded." Done is that the source system is switched off, its data archived under a retention schedule someone can point to, the reports the business runs on coming from one place, the final dual-run reconciliation signed, and the entity-resolution rules running as production jobs with a review queue that has an owner. Until the source is off, the acquisition keeps accruing cost in licenses, hosting, security coverage and the attention of whoever maintains it.

Set the decommission date at the start and manage against it. Programs that track "percent of tables migrated" reach ninety percent and stop, because the last ten percent is where the unassignable license, the legal hold and the report nobody documented all live.

Bottom line

Post-acquisition data integration is a decision problem with an engineering tail. Two systems of record disagree, and the program exists to arbitrate and prove the result. Before close, build the metadata inventory and let counsel set the line on everything else. After close, tag the restricted classes first and design containment around the strictest one present. Do entity resolution with measured precision and recall rather than a match-rate headline. Make the reconciliation the deliverable. Put a retirement date on every source system, including the ones you decided to keep. A team that does those five things ships a combined estate; a team that starts with the pipeline ships a copy of two problems.

Frequently asked questions