What Should Survive an Acquisition?

The easiest integration decision is choosing one system.

The harder decision is recognizing which knowledge, customer promises, safeguards, and recovery paths the other system was quietly carrying.

An acquisition can transfer legal ownership on a closing date. It cannot instantly combine operating models. People, products, contracts, data, identities, suppliers, customer relationships, service processes, security controls, and unwritten ways of getting difficult work done still have to be understood and connected.

Current public filings make the scope visible. Capital One's 2025 Form 10-K describes its Discover integration across operations, systems, networks, technology, compliance, risk management, controls, culture, customer relationships, personnel, pricing, benefits, cybersecurity, vendor management, finance, payroll, and lines of business. That disclosure does not tell us whether the integration has succeeded or failed. It shows the breadth of operating-model work that can continue after ownership has legally changed. (https://www.sec.gov/Archives/edgar/data/927628/000092762826000024/cof-20251231.htm)

Having worked across organizations shaped by multiple acquisitions, I have seen how much operational knowledge can live outside the formal integration plan. It may be encoded in an application, but it may also live in a contract exception, an escalation path, a carrier relationship, a customer promise, a recovery procedure, a data definition, or the experience of the person who knows why the process works that way.

This is not an argument against acquisitions, centralization, or standardization. Each can create real value. It is an argument for treating integration as a portfolio of decisions rather than one default instruction to consolidate everything.

My practitioner framework gives every capability, process, platform, data set, service, and control one current treatment:

The framework is intentionally called a current treatment. The right answer can change as dependencies are removed, evidence improves, customers migrate, and the organization learns.

The capability is bigger than the application

Integration inventories often begin with applications, contracts, facilities, and headcount. Those are necessary, but they do not describe the complete operating capability.

Consider a customer-support platform. Its visible components may be software licenses, servers, workflows, queues, and reports. The working capability may also include entitlement rules, severity definitions, special routing, privacy restrictions, emergency procedures, after-hours contacts, carrier dependencies, customer-specific commitments, and people who know how to recover when the documented path fails.

Recent research supports putting relevant operating knowledge into the decision loop. An April 2026 NBER working paper found that target-industry experience among business-unit leaders responsible for integration was associated with better planning, more successful integration, fewer measured failures, and better synergy realization. The paper uses natural-language-processing measures and financial metrics, so it should not be treated as proof that experience alone guarantees success. It does support a practical point: integration leadership benefits from people who understand the market and operating conditions of what was acquired. (https://www.nber.org/papers/w35074)

A 2026 peer-reviewed Organization Science study adds a second form of knowledge. Across 2,941 acquisitions and 18,987 target managers, the researchers found that structural similarity and managers' aligned structural experience were associated with higher retention in related acquisitions. They describe structural knowledge as knowing how tasks, relationships, routines, and decision paths are coordinated within an organizational design. That is different from knowing the product or technology. The findings are associational, focus on top managers, and use transactions from 1994 through 2018, but they help explain why apparently duplicated management knowledge may still matter during integration. (https://pubsonline.informs.org/doi/10.1287/orsc.2024.18686)

This does not mean that the longest-tenured person is automatically correct or that acquired practices should escape review. It means the people making the classification need access to technical knowledge, structural knowledge, customer evidence, security evidence, financial evidence, and the authority to challenge a convenient but incomplete inventory.

Five treatments, not one default

1. Standardize

Standardize when a common definition, control, process, or platform improves safety, clarity, speed, or economics without destroying a meaningful difference.

Good candidates may include identity proofing, privileged-access rules, incident-severity language, baseline security controls, financial-close requirements, supported configurations, and shared reporting dimensions. Standardization is valuable when people should receive the same answer, follow the same safety rule, or produce comparable evidence.

Before selecting the standard, compare requirements, customer impact, regulatory and contractual obligations, control strength, migration dependencies, exception volume, recovery needs, and the cost of being wrong. The acquiring organization's existing process is not automatically the best target merely because it is already central.

2. Interoperate

Interoperate when distinct systems or operating models still create value, but they need a reliable way to exchange information or coordinate work.

Examples may include product platforms, customer portals, regional service environments, carrier systems, specialist engineering tools, and partner ecosystems. The design work is not only an API. It includes the interface contract, system-of-record ownership, data meaning, identity, authorization, availability, failure behavior, support ownership, logging, and lifecycle commitments.

Interoperability should not become permanent ambiguity. Every interface needs an owner, a defined source of authority for each exchanged element, a failure path, a security boundary, and a review date.

3. Preserve

Preserve when a capability, relationship, workflow, product identity, culture, or control is part of the value that justified the acquisition or satisfies a distinct customer, legal, regulatory, or safety obligation.

Preservation can be a deliberate business choice rather than resistance to integration. When IBM completed its acquisition of Red Hat, it publicly said that preserving Red Hat's independence and neutrality was important to maintaining partnerships, customer choice, and flexibility. That announcement establishes IBM's stated treatment and rationale, not proof that every later result came from it. (https://www.ibm.com/investor/news/ibm-completes-acquisition-of-red-hat)

Pearson's 2025 annual report offers a more recent example of the decision process. In considering an acquisition, its board reported that retaining the acquired team's skills and entrepreneurial spirit mattered, and that the integration plan was intended to be co-created and co-owned with that team. Again, this is a disclosed intention, not a measured outcome. It shows that preservation and collaborative integration can be explicit governance decisions. (https://www.sec.gov/Archives/edgar/data/938323/000119312526105140/d51141dex991.pdf)

Preserve does not mean exempt. A preserved capability still needs ownership, performance measures, access governance, monitoring, incident response, continuity planning, and periodic review.

4. Temporarily coexist

Temporarily coexist when immediate consolidation creates unacceptable customer, operational, security, regulatory, or continuity risk, but indefinite duplication is not the goal.

Directories, billing platforms, contact-center environments, service desks, customer databases, and contract-specific delivery models often require sequenced transitions. A legal combination can be immediate while customers, data, identities, and workflows move in controlled waves.

Coexistence must be designed. It needs segmentation, minimum control requirements, named owners, credential and trust rules, synchronization logic, support coverage, cost visibility, migration waves, rollback conditions, and evidence-based exit criteria. An arbitrary deadline can create unmanaged migration risk, while indefinite coexistence creates unmanaged complexity and cost.

The question is not whether coexistence looks inefficient on an architecture diagram. The question is whether its current risk is lower than the risk of migration today, and which evidence will show when that balance changes.

5. Retire

Retire when the capability is genuinely duplicative, unsupported, uneconomic, or no longer required, and when its obligations have moved or ended.

Low usage is evidence, but it is not enough. A lightly used system may still carry records-retention requirements, contract-specific routing, regulatory evidence, emergency access, data lineage, a rollback path, or one customer workflow that has not migrated.

Before retirement, confirm the dependency inventory, replacement acceptance, customer transition, records disposition, access revocation, data sanitization, monitoring changes, backup or archive decision, and recovery plan. NIST's business-impact guidance emphasizes understanding mission-essential functions and the assets that enable them before risks and responses are prioritized. Applying that principle to retirement helps distinguish genuine duplication from an infrequently used but critical dependency. (https://csrc.nist.gov/pubs/ir/8286/d/upd1/final)

Retirement is complete only when the system, its trust relationships, its data obligations, and the operating responsibility around it have all been addressed.

Reconcile meaning before combining the dashboard

Business Intelligence can help integration leaders track whether indicators for migrations, service levels, customer retention, access cleanup, and cost are moving as intended. It can also create false confidence if two organizations use the same words differently.

“Customer” may mean a legal account, an invoice recipient, a physical location, an entitled support contact, an active user, or a subscription. “Revenue” may mean booked, invoiced, recognized, recurring, or collected revenue. “Resolved” may mean that an engineer completed the work, that monitoring recovered, or that the customer confirmed success.

Putting those values into one shared data platform does not make them equivalent. A technically valid transfer can still lose business meaning.

OMB's 2025 federal data guidance provides a useful operational model even though it is not private-sector M&A law. Its inventory requirements include data descriptions, variable names and definitions, access restrictions, location, maintainers, and owners. It also defines machine-readable data as processable without human intervention while preserving semantic meaning, and it treats source, accuracy, provenance, granularity, and responsible parties as metadata. (https://www.whitehouse.gov/wp-content/uploads/2025/01/M-25-05-Phase-2-Implementation-of-the-Foundations-for-Evidence-Based-Policymaking-Act-of-2018-Open-Government-Data-Access-and-Management-Guidance.pdf)

Pearson's annual report shows the executive side of the same problem. It says the board adopted standardized revenue-view definitions across customer segmentation, business model, and innovation to improve transparency and organizational accountability. That is one company's disclosed approach, but it shows that a board can treat metric definitions as a governance decision, not merely report formatting. (https://www.sec.gov/Archives/edgar/data/938323/000119312526105140/d51141dex991.pdf)

A defensible sequence is:

1. Inventory the inherited sources, definitions, owners, maintainers, access restrictions, and effective dates.
2. Designate authoritative sources by domain and purpose instead of declaring one universal source of truth.
3. Trace lineage: document where each measure originated and how transformations and calculations changed it.
4. Reconcile definitions and document justified differences.
5. Publish combined measures only after accountable business owners review and approve the mapping between definitions.
6. Preserve local measures where their differences remain meaningful.
7. Track relevant customer, financial, service, workforce, and risk outcomes without assuming that every later change was caused by the integration decision.

The dashboard should expose uncertainty and definition changes, not hide them behind a cleaner chart.

Security integration starts before broad connectivity

Legal ownership, by itself, does not establish technical trust.

In May 2026, Microsoft's operating CISO advised organizations to consider the risks of combining tools and technical capabilities too quickly, whether a deal remains valuable without immediate systems integration, and which safeguards and governance are needed. This is practitioner guidance from Microsoft, not a controlled study, but the questions are exactly the right ones. (https://www.microsoft.com/insidetrack/blog/microsoft-ciso-advice-consider-the-risks-of-early-integration-with-mergers-and-acquisitions/)

Where transaction rules permit, this work should begin during due diligence and continue through Day 1. Record what can be verified before close, which unknowns remain, who owns each inherited risk, and what conditions must be met before broad trust is established. Due diligence reduces uncertainty; it does not certify that an inherited environment is secure.

The Marriott and Starwood matter illustrates the risk of inheriting an environment before gaining full visibility. In its complaint, the FTC alleged that the second breach began in Starwood's environment in July 2014, before Marriott's 2016 acquisition, and remained undetected until September 2018, nearly two years after legal close. The complaint identified alleged deficiencies including firewall controls, multifactor authentication, monitoring, and logging; the FTC's press release also listed patching, password and access controls, and network segmentation. The FTC later finalized a consent order. The respondents neither admitted nor denied the allegations except as stated in the order, and the acquisition did not cause the original intrusion. The narrower lesson is that responsibility can transfer before visibility does. (https://www.ftc.gov/news-events/news/press-releases/2024/10/ftc-takes-action-against-marriott-starwood-over-multiple-data-breaches) (https://www.ftc.gov/system/files/ftc_gov/pdf/1923022marriottcomplaint.pdf) (https://www.ftc.gov/system/files/ftc_gov/pdf/1923022marriottfinalorder.pdf)

Security integration should establish, before broad connectivity:

• Verified inventories, with known gaps documented, covering systems, software, services, APIs, data, suppliers, identities, credentials, and trust relationships
• Ownership for each environment and each material risk
• Privileged-account review, former-employee cleanup, risk-based credential rotation or replacement, and multifactor-authentication coverage
• Segmentation and narrowly authorized connection paths
• Data classification, retention, privacy, and transfer rules
• Central monitoring without discarding native logs before timestamps, context, retention, and forensic usefulness are verified
• Compatible incident-response, recovery, communication, and business-continuity procedures
• Review of inherited vendor access, remote-support paths, software dependencies, and open control findings

This checklist is a practitioner synthesis, not a single M&A standard. NIST CSF 2.0 supports inventories of hardware, software, services, systems, supplier services, data, and network flows. CISA guidance supports account review, multifactor authentication, centralized logging, and segmentation, although those CISA publications are general security guidance rather than M&A requirements. (https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20) (https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure) (https://www.cisa.gov/news-events/alerts/2025/07/29/cisa-releases-part-one-zero-trust-microsegmentation-guidance)

Although NIST SP 800-63C-4 is digital identity guidance, not an M&A standard, it requires documented trust agreements between identity providers and relying parties. In a post-acquisition environment, shared legal ownership does not remove that technical design work. The guidance also notes that ending a session at the identity provider will not necessarily end downstream application sessions, so account termination, revocation signaling, and session management have to be designed across the complete path. (https://csrc.nist.gov/pubs/sp/800/63/c/4/final)

Do not establish broad trust first and govern later. Start with limited, observable paths, preserve the evidence needed for investigation and continuity, standardize minimum controls, and retire unnecessary trust only after dependencies are understood.

Where applied AI can help, and where it cannot decide

Acquisitions create dispersed information that AI-assisted search and comparison may help teams navigate: policies, data structures, contracts, tickets, diagrams, access lists, configuration records, support histories, and years of documentation written by different groups.

With representative testing and human review, AI may help compare policies, propose candidate data mappings, surface conflicting definitions, group apparently similar workflows, extract documented dependencies, draft migration test cases, and improve search across dispersed knowledge. These are leads for investigation, not decisions about equivalence, authority, access, or retirement.

Published evidence is promising but narrow. A 2025 EMNLP study from IBM Research reported gains with a hybrid method that combined a large language model with embeddings for semantic attribute alignment, but its experiments used healthcare schemas. It supports using AI for candidate discovery, not autonomous reconciliation. (https://research.ibm.com/publications/group-embed-and-reason-a-hybrid-llm-and-embedding-framework-for-semantic-attribute-alignmen)

Without source, version, and permission controls, the same system may merge incompatible definitions into a persuasive answer, expose information across an inherited access boundary, recommend retirement without recognizing an undocumented customer obligation, or present an obsolete policy as current.

OWASP's 2025 guidance warns that retrieval-augmented AI can expose information to the wrong user, mix contradictory sources, or ingest poisoned material. It recommends enforcing each user's permissions during retrieval, separating datasets where required, validating sources, classifying data, reviewing combined datasets, and logging retrieval activity. OWASP is community security guidance, not a statistical estimate of prevalence, but it provides a useful control checklist for an AI search system spanning inherited information. (https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/)

NIST's current agentic-AI evaluation project is developing probes that compare agent claims with a human-curated corpus and create structured audit trails showing what the agent found, where it found it, and whether the evidence supports the conclusion. The project is ongoing research, not a finished standard, but its direction is valuable for integration work. (https://www.nist.gov/programs-projects/building-evaluation-probes-agentic-ai)

A safer division of labor is:

• AI surfaces candidate matches, conflicts, anomalies, dependencies, and supporting evidence for review.
• Business Intelligence reports governed measures of the current state and outcomes, using approved definitions and traceable sources.
• Security architecture and platform controls constrain which sources, identities, actions, and environments are reachable.
• Accountable people decide meaning, authority, obligations, treatment, timing, exceptions, and acceptable risk.

For a high-consequence question, the audit record should retain the query, retrieved sources, source versions, permission context, metric definitions, generated output or recommendation, reviewer decision, and later outcome when available. A citation added after generation is not the same as a traceable evidence record.

The first applied step is not to ask AI what to retire. It is to build a reviewable capability map that connects systems to owners, customer promises, controls, dependencies, definitions, evidence, and unresolved questions.

The Applied AI Companion for this issue turns that starting point into a bounded workflow, with source permissions, provenance, human approval, testing, and measurable outcomes kept visible. It is also available for reading and discussion on LinkedIn.

An operating loop for integration without erasure

The framework becomes useful only when it changes how decisions are made.

1. Inventory the real operating capability

Capture applications and headcount, but also customer promises, contractual obligations, data definitions, interfaces, third parties, identities, security controls, exception processes, informal escalation paths, specialist knowledge, trusted relationships, and recovery procedures.

2. Establish ownership and meaning

Name the business owner, technical owner, security owner, authoritative source or sources by domain and purpose, who approves each definition, and the people qualified to explain why the capability exists.

3. Classify the current treatment

Choose standardize, interoperate, preserve, temporarily coexist, or retire. Record the evidence, uncertainties, decision authority, customer impact, security impact, review date, success measures, and recovery path.

4. Integrate security and continuity into the treatment

Every treatment needs access boundaries, monitoring, incident response, data handling, supplier governance, and recovery. Preservation without governance can leave unmanaged risk. Standardization without tested recovery can concentrate operational risk.

5. Execute in observable, reversible stages

Use controlled migration waves, limited trust, independent validation, customer-visible acceptance criteria, and rollback conditions. The size and speed of each stage should reflect consequence, not impatience.

6. Measure the outcome

Useful signals may include customer churn, support transfers, exception volume, cross-team incident-resolution time, access-entitlement differences, migration defects, rollback events, service availability, key-person dependency, time from decision to implementation, and the continuing cost of coexistence.

These are candidate measures, not universal key performance indicators. The correct measure depends on the reason the treatment was chosen.

7. Learn and reclassify

Integration routines should improve through evidence. A capability preserved during the first year may later interoperate or standardize. A planned retirement may be delayed when a hidden obligation appears. A temporary interface may become a durable product boundary. The treatment changes when the evidence changes.

The leadership decision

The goal is not to protect complexity. The goal is to simplify without accidentally discarding the capability, trust, evidence, or safeguard that made the acquisition valuable.

Leaders should ask:

• What value or obligation does this capability carry today?
• What breaks if it disappears?
• Which customers, contracts, regulations, systems, people, and recovery paths depend on it?
• Who understands both the acquired capability and the target operating model?
• What should be common, and what should remain distinct?
• What evidence will show whether the decision worked?
• Can the decision be reversed if the evidence says it was wrong?