A financial and legal review rarely surfaces what the technology environment actually looks like: what runs on unsupported systems, which licenses cannot transfer, or how much integration work the deal quietly assumes. IT due diligence answers that separately.
The decision to enable
Decide what technology risk, cost, and integration effort a transaction actually carries—identified before close, not discovered after.
01
Inventory what actually exists, not what the org chart implies
Confirm the real list of systems, vendors, licenses, and administrative access—including anything run by a single person’s informal setup that never made it into a formal inventory. What is undocumented is not automatically absent; it is simply unverified.
Systems and vendors not covered by a written contract
Administrative access tied to individuals, not the organization
Data and systems the target organization considers critical
02
Test whether licenses and contracts actually transfer
Software licenses, domain registrations, and vendor contracts are not automatically assignable in a transaction. Confirm transferability, required consents, and any change-of-control clause before assuming existing agreements simply continue under new ownership.
03
Price integration and technical debt honestly
Two organizations rarely run compatible systems. Estimate what it actually takes to integrate, replace, or run systems in parallel—including the internal time this requires—rather than treating integration as a detail to solve after close.
04
Confirm the security and access baseline before, not after, close
A spot check of access control, backup verification, and known unresolved incidents belongs in diligence, not in the first month of ownership. Record what was checked, what was not, and what remains an open question at close.
Decision frame
What leadership should be able to verify.
These criteria do not produce a score. They expose the questions that need resolution before a responsible decision.
CriterionUseful signalLeadership question
InventorySystems, licenses, and access are documented beyond what the org chart shows.What runs on a system or account that only one person understands?
TransferabilityLicense and contract transfer terms are confirmed, not assumed.Which agreements require consent or change-of-control notice to continue?
Integration costThe real effort to combine or replace systems is estimated, not deferred.What does it actually take to make these two environments work together?
Security baselineAccess control and backup verification are spot-checked before close.What was actually checked, and what remains an open question?
Practical scenarios
The same discipline applied to different decisions.
A target organization runs critical systems on personal or informal accounts
Situation: Diligence finds that a domain, a critical vendor account, or administrative access is tied to a departing individual’s personal credentials.
Useful response: Treat this as a required remediation before close, not an acceptable finding to fix later—confirm a path to organizational control of every critical account.
Boundary: This guide does not perform the technical remediation or draft the legal transfer terms.
Two merging organizations run different, incompatible core systems
Situation: Neither party is willing to fully adopt the other’s system, and a combined roadmap has not been discussed before signing.
Useful response: Name the integration decision explicitly as a post-close priority with an owner and a timeline, rather than leaving it as an assumption both sides interpret differently.
Boundary: This guide frames the decision; it does not select or implement a specific integration path.