I have spent much of my career inside organizations that changed through acquisition. The paperwork can make a combination official on a particular day. The real integration takes much longer because customers, systems, people, contracts, and ways of working do not reorganize themselves at closing.
That work has taught me to be careful with the word "duplicate." Two teams may appear to do the same job. Two applications may seem to hold the same data. Two processes may have the same label. Look closer, though, and one may carry a customer promise, a recovery path, or an exception that the other never had to handle.
I believe in simplifying. I also believe that you should understand a capability before changing it. My best work in these situations has usually involved building a bridge between the people who know why something works and the people responsible for what comes next.
Look past the application inventory
An application inventory is useful, but it is only the beginning. A working capability can include software, data, contracts, supplier relationships, routing rules, security controls, support practices, and people who know what to do when the documented path fails.
That last part is easy to underestimate. A 2026 NBER working paper found that relevant target-industry experience among leaders responsible for integration was associated with better planning, fewer measured integration failures, and better synergy realization. A separate 2026 Organization Science study calls attention to "structural knowledge," meaning the experience of how work, relationships, and decisions are coordinated within an organization. Both studies have limits, but they reinforce something I have seen repeatedly: the person who understands how the pieces actually fit may be carrying part of the capability. (NBER, Organization Science)
That does not mean every inherited practice should survive, or that experience makes someone automatically right. It means the people making integration decisions need to hear from those who understand the technology, the customers, the business rules, and the failure modes. That conversation works best when it is collaborative and evidence can challenge anyone's assumptions.
Five choices for what you inherit
I use five possible treatments when I look at an inherited system, process, data set, service, or control. The treatment is a current decision, not a permanent label. It can change as dependencies are removed, customers migrate, and the combined organization learns.
- Standardize when a common process, definition, control, or platform will make the organization safer, clearer, or easier to operate. Identity proofing, privileged-access rules, incident-severity definitions, and financial-close requirements are good places to look for consistency. The acquirer's method should not win by default. Compare obligations, control strength, customer impact, migration risk, and the cost of being wrong.
- Interoperate when two distinct capabilities still have value, but they need a dependable way to exchange information or coordinate work. An interface is more than an API. Someone has to own the data meaning, authorization, failure handling, monitoring, and support path on both sides. Interoperability is useful when it is intentional. It becomes another source of confusion when nobody can say which system is authoritative or what happens when the connection fails.
- Preserve when independence, specialist knowledge, customer trust, partner relationships, or a particular way of working is part of what the transaction acquired. Preservation can be an explicit business decision. When IBM completed its acquisition of Red Hat, IBM said it would preserve Red Hat's independence and neutrality to support existing partnerships, customer choice, and flexibility. That announcement explains IBM's stated intent. It does not establish what produced later results. It is a clear example of an acquirer recognizing that sameness was not the goal. (IBM)
- Temporarily coexist when immediate migration would create more customer, operational, regulatory, or security risk than a controlled transition. Directories, billing systems, contact-center platforms, and customer databases often move in stages. "Temporary" still needs discipline: named owners, minimum controls, support coverage, migration waves, rollback conditions, cost visibility, and a review date. A rushed deadline can hide migration risk. An endless transition can hide cost and complexity.
- Retire when something is truly duplicative, unsupported, uneconomic, or no longer required. Low usage is not enough evidence by itself. A lightly used platform may still carry records, emergency access, contract-specific routing, data lineage, or a customer workflow that has not moved. Retirement is finished only after the responsibility, data obligations, access paths, monitoring, and recovery needs around the system have also been addressed.
The five choices help move a discussion beyond "ours or theirs." They give people a shared way to explain what a capability does today, why a treatment makes sense, what evidence is still missing, and when the decision should be reviewed again.
Get the meaning right before combining the numbers
Business Intelligence can give leaders a clearer view of migration progress, service performance, customer retention, access cleanup, and cost. It can also make a bad assumption look authoritative.
Take the word "customer." One organization may mean a legal account. Another may mean an invoice recipient, a location, an entitled support contact, an active user, or a subscription. "Revenue" may mean booked, invoiced, recognized, recurring, or collected revenue. Moving both organizations' data into one platform does not make those definitions equivalent.
Before publishing a combined measure, I want to know what each source means, who owns it, when the definition applies, how the value was calculated, and which differences still matter. Federal data guidance from the Office of Management and Budget provides a useful model, even though it is not a private-sector acquisition rule. It calls for inventories that include data descriptions, variable definitions, access restrictions, and responsible parties, and it treats source, accuracy, provenance, and granularity as metadata. (OMB M-25-05)
The practical sequence is straightforward: inventory the sources and definitions, identify accountable owners, trace how each measure was produced, reconcile what can honestly be combined, and preserve clearly labeled differences where it cannot. A good dashboard should reveal uncertainty and definition changes. It should not bury them under a cleaner chart.
AI can help with the discovery work. It can compare documents, propose possible field mappings, surface conflicting definitions, and find dependencies for a person to investigate. It should not decide which definition is authoritative, which customer promise can be dropped, or which system is safe to retire. Those are accountable business decisions. Part 2 will show how I would use AI to make that work faster while keeping the evidence and approvals visible.
Establish responsibility before broad connectivity
Security belongs inside the integration decision from the start. Legal ownership does not make an inherited identity, network, supplier connection, or administrative account trustworthy. NIST's current federation guidance is unusually direct on this point: it requires trust agreements for federation transactions even when the systems share legal ownership. (NIST SP 800-63C-4)
Before broad connectivity, I want a verified inventory, known gaps, an owner for each environment, and a clear record of who accepts each inherited risk. I also want privileged accounts reviewed, former-user access removed, trust paths documented, logging preserved, data handling understood, and recovery procedures tested across both organizations. Connections should begin through limited, observable paths, with enough segmentation to contain a problem and enough evidence to investigate one.
The Marriott and Starwood case shows why the order matters. According to the FTC's complaint, an intrusion began in Starwood's environment in 2014, before Marriott acquired the company in 2016, and remained undetected until 2018. The complaint alleged weaknesses involving access controls, multifactor authentication, segmentation, logging, and monitoring. The FTC later finalized a consent order. The acquisition did not cause the original intrusion, and the complaint was not a judicial finding after trial. The useful lesson is narrower: responsibility can transfer before visibility does. (FTC complaint, case record and final order)
Integration can improve security by bringing systems under stronger controls, shared monitoring, and clearer accountability. It can also expand the blast radius if trust is granted before the inherited environment is understood. The safest path is the one that makes ownership, access, evidence, and recovery explicit before convenience drives the connection.
Make the decision visible, and keep listening
For each capability, I would record the current treatment, the reason, the owner, the customer impact, the security impact, the unknowns, the success measures, the review date, and the recovery path. Then I would execute in stages that can be observed and, where practical, reversed.
The measures will vary. A customer migration may be judged by defects, support transfers, cancellations, and successful rollback tests. Identity consolidation may be judged by entitlement differences, stale-account removal, authentication failures, and incident response. A period of coexistence should show its cost, its risk, and the evidence required to end it.
Most important, keep listening after the first decision. A capability preserved during the first year may later be ready to standardize. A planned retirement may pause when a hidden obligation appears. A temporary interface may prove to be a sensible long-term boundary. Changing the treatment when the evidence changes is not indecision. It is responsible integration.
The goal is not to protect complexity for its own sake. It is to simplify without discarding the customer commitment, operational knowledge, or safeguard that made the acquired capability valuable.
After repeated acquisitions, I remain optimistic about what a combined organization can become. The strongest integrations I have seen did more than connect systems. They created enough trust for people to explain what mattered, enough discipline to test those claims, and enough shared purpose to build something better together.
Also available on LinkedIn.