Technology due diligence timeline for M&A deals

A two-week technology review can support an acquisition decision, but only when the deal question is narrow and the seller can produce evidence on day one. Four weeks buys more than extra interviews. It gives the buyer time to test disputed claims, trace dependencies, price remediation, and see how the team responds when the first answer does not hold up.

I have seen deals waste half of their review window asking for access that should have existed before kickoff. I have also seen buyers burn four weeks collecting screenshots without deciding which findings could change price, structure, or the first 100 days. The calendar alone tells you nothing. A useful timeline connects each question to evidence, an owner, a decision, and a deadline.

The right planning unit is not a meeting or a document. It is a claim that the buyer needs to accept or reject: the platform can handle the growth plan, the company owns the software it is selling, a small team can operate it, security exposure is contained, or a migration will not swallow the integration budget. Sellers move quickly when they can prove those claims. Buyers move quickly when they say what each answer will change.

The clock measures evidence latency

A technology due diligence timeline depends on how long it takes to retrieve and test evidence, not on how many topics appear in a request list. Architecture, security, delivery, infrastructure, data, team, intellectual property, and cost always appear. A prepared company can expose much of that record in hours. An unprepared company needs days to find it, reconcile contradictions, and work out who may share it.

Evidence latency has four parts. Retrieval is the time required to locate a record. Access is the time required to approve the reviewer and grant the least privilege needed. Interpretation is the time an informed owner needs to explain what the record means. Verification is the time the buyer needs to compare the explanation with repositories, cloud configuration, incident history, or financial data. A seller who improves only retrieval still stalls if legal approval arrives on day six or nobody can explain an abandoned service.

This distinction matters because interviews are claims, while operating records are evidence. A CTO can say deployments happen daily. The deployment history can show frequency, failure clusters, manual gates, and which person has permission to release. A security questionnaire can say access reviews occur. Identity-provider exports and closed review tickets can show whether they actually occur and whether departures were handled.

Start the schedule by tagging every request with an expected source and a decision use. If a request has no decision use, remove it. If a claim has no expected source, mark it as an interview lead rather than a verified fact. That small discipline prevents a large data room from creating false confidence.

Two weeks fits a bounded decision

Two weeks is enough when the buyer needs a directional risk assessment and the target has one principal product, a legible architecture, reachable owners, and current operating evidence. It is also enough for many smaller transactions where technology affects the decision but does not require a detailed separation, migration, or regulatory plan before signing.

A sound two-week review can establish five things. It can identify the architecture and its main failure domains, test whether delivery records support management's claims, inspect the highest exposure security controls, reconcile engineering headcount and vendor cost, and separate closing risks from integration work. It can also spot intellectual-property gaps if contracts, contributor records, dependency inventories, and repository access are ready at kickoff.

The boundary needs to be explicit. A two-week report should say where the team sampled rather than inspected exhaustively. For example, the reviewer might trace the three services responsible for most customer traffic, examine the last several production incidents, inspect privileged access paths, and test the build and deployment process for the main product. That work supports a decision about material risk. It does not certify that every repository, cloud account, or dependency is clean.

Two weeks fails when the buyer quietly expects both a transaction opinion and a complete remediation design. Pricing a cloud consolidation, validating a complex data migration, or proving that a regulated workload meets every applicable control usually needs deeper access and more specialists. Put those tasks into the purchase agreement, a focused follow-on review, or the integration plan. Pretending they fit only produces confident estimates with weak foundations.

The seller also has to protect normal operations. Give reviewers named technical contacts and office hours instead of routing every question to the CTO. A single channel for clarifications keeps answers consistent, while a request owner prevents five people from producing different versions of the same fact. Speed comes from ownership, not from asking engineers to remain permanently available.

Four weeks is for uncertainty and economics

Four weeks is justified when the review must turn unknowns into priced work. The extra time lets a buyer follow a finding across system boundaries, check whether an exception is isolated, obtain specialist input, and estimate the people, licenses, infrastructure, and downtime involved in fixing it. Those are transaction inputs, not technical decoration.

Complexity often hides outside the product repository. A company may run several acquired codebases, regional cloud estates, customer-specific forks, an on-premise edition, or shared services owned by the seller's parent. The architecture diagram can look tidy while identity, billing, observability, and data exports cross every boundary. A reviewer needs time to trace those dependencies and decide whether they transfer with the deal.

A carve-out nearly always pushes the work toward four weeks because the buyer must distinguish assets from services. Source code might transfer on closing, while build runners, signing keys, support tooling, domain administration, security monitoring, and staff accounts remain in the parent environment. Each shared dependency needs an owner, a replacement path, a transition service if necessary, and an end date. Missing one can stop releases even when the product itself runs correctly.

Regulated or sensitive data also lengthens the review. The buyer may need counsel or a specialist to interpret obligations, but the technical team still must prove where data enters, where it is stored, which processors receive it, how deletion works, and how backups affect retention. A policy is not enough. The reviewer needs configuration, data-flow evidence, selected tickets, and a demonstration of the actual process.

Use four weeks when early evidence contradicts management. If the data room says the platform uses one cloud account but billing shows several, do not average the answers. Trace the discrepancy. If leadership reports no material incidents but the issue tracker shows recurring emergency fixes, inspect incident definitions and escalation practice. Contradictions often reveal weak ownership before they reveal misconduct, but either explanation changes integration risk.

A decision-led schedule keeps fourteen days useful

A disciplined two-week review front-loads access and reserves the final days for challenge, not collection. I use the following cadence when the scope is bounded and the seller is ready. Business days matter here because access approvals and expert availability tend to disappear over weekends.

This schedule assumes the buyer sends the request list before kickoff. Day one is too late to begin security review of reviewer accounts, repository permissions, confidentiality limits, or export restrictions. The seller should test each account and file from the perspective of an external user. Internal links that only work on the company network are not delivered evidence.

A four-week schedule should not stretch these activities evenly. Keep the same fast first pass, then use weeks three and four for the few findings with transaction weight. One track might model the cost of separating infrastructure. Another might validate an intellectual-property concern or run a focused security assessment. The final week should reconcile those tracks into one commercial view.

Set escalation thresholds before evidence arrives. A reviewer should know whether an unsupported component, a single-person operating dependency, an unbudgeted infrastructure commitment, or a missing assignment agreement triggers deeper work. Otherwise every interesting technical detail competes for time, and the report grows while the decision gets blurrier.

Do not schedule the management readout as the first moment executives see a serious finding. Share material factual issues with the designated seller lead as soon as the evidence supports them. That gives the seller time to produce missing context and gives the buyer time to distinguish a correctable fact error from a genuine risk. Surprise makes meetings dramatic, but it rarely improves the decision.

The evidence index is the seller's fastest tool

A seller speeds up diligence by delivering a controlled evidence index, not by dumping folders into a data room. The index maps each buyer question to a current artifact, an owner, a date range, an access level, and any known limitation. It should also state when no artifact exists. A candid gap on day one is easier to assess than a silent gap discovered after three reminders.

A compact index can look like this:

- id: SEC-04
  question: privileged access review
  owner: security-lead
  evidence: idp/export-privileged-users.csv
  period: current plus prior review
  access: restricted-reviewer
  limitation: break-glass account reviewed separately
- id: OPS-07
  question: production incident history
  owner: platform-lead
  evidence: incidents/closed-12-months.csv
  period: trailing 12 months
  access: diligence-room
  limitation: customer names redacted

The exact format does not matter. The fields do. Every row gives the reviewer somewhere to start and someone to ask. Version the index, record replacements, and keep redactions consistent. If a file changes, preserve the earlier version and explain why; unexplained replacement creates more concern than an ordinary correction.

Sellers should prepare a claim-to-evidence matrix before a buyer sends questions. Put the investment claims in the first column: deployment speed, scalability, security discipline, ownership of software, low operating cost, or independence from one engineer. Put the evidence that could disprove each claim in the next column. That second column is uncomfortable, which is why it works. It exposes where management has been repeating a belief that operations cannot yet support.

Do not manufacture clean records for the review. Recreated diagrams should carry a creation date and an owner. If the team writes an architecture decision after receiving the request, label it as a current explanation rather than historical evidence. Buyers tolerate immature documentation more readily than documents designed to look older or more settled than they are.

Repository access should answer operating questions

Repository review should show whether the buyer can build, test, release, and maintain the software with the people and rights that will transfer. Counting repositories, languages, or lines of code does not answer that question. The reviewer needs to find the production path, ownership boundaries, dependency policy, release controls, and evidence of work that repeatedly bypasses the stated process.

Ask the seller to identify the canonical repositories and then reconcile that list with build systems and deployment records. Archived experiments matter less than a tiny live repository that holds database migrations or infrastructure definitions. Forks and mirrors need a stated purpose. Personal repositories used by production jobs create an ownership and continuity risk even when the code quality is fine.

A reviewer can request a seller-run inventory when direct cloning is inappropriate. The following commands expose the shape of a Git repository without sending source code to another service:

git shortlog -sne --all | head
git log --since='12 months ago' --pretty='%ae' | sort -u
git ls-files | sed 's#^#/#' | cut -d/ -f2 | sort | uniq -c | sort -nr | head
git log -1 --format='%H %cI'

The output should contain author counts and addresses, the distinct recent contributor addresses, top-level path counts, and the latest commit hash with its timestamp. It can reveal concentration, dormant ownership, or an inventory mismatch. It cannot prove productivity, code quality, or legal ownership, so do not turn commit counts into a performance score. Use the output to choose interviews and samples.

Software composition tools deserve the same restraint. A dependency list can identify licenses, unsupported versions, and components that need review. It does not by itself prove exploitability or breach. The OWASP Application Security Verification Standard separates verification requirements by control area; that is a better model than treating one scanner's severity label as a transaction verdict. Test whether the relevant control exists in the deployed path and record the exposure conditions.

Intellectual-property review also needs legal ownership evidence outside Git. Employee and contractor assignment terms, open-source obligations, acquired code, third-party SDK rights, and customer-funded custom work can all affect what transfers. Technical reviewers should map the code and contributors; qualified counsel should interpret the agreements. Mixing those roles leads either to shallow legal conclusions or to technical issues that never reach counsel.

Security findings need exposure and ownership

A security finding belongs in the deal memo when the team can explain the affected asset, realistic exposure, control failure, remediation owner, and transaction consequence. A long vulnerability export without that chain is backlog material. It may still matter after closing, but it should not crowd out an exposed administrative path or a missing incident response owner.

Start with identity, production access, secrets, internet exposure, data handling, incident history, backups, and software delivery. These areas connect quickly to continuity and liability. Sample records across time instead of accepting one freshly cleaned screenshot. A current user export plus prior review tickets, for example, can show both present state and whether the control operates repeatedly.

The NIST Secure Software Development Framework treats secure development as a set of organizational practices across preparation, software protection, production, and vulnerability response. That framing is useful in diligence because it asks who owns repeatable work. I would qualify it for a transaction: buyers do not need equal depth in every practice before signing. They need evidence on practices tied to the target's actual exposure and the acquisition thesis.

Severity and materiality are different. A critical library finding may sit in an unreachable test utility. A moderate identity weakness may expose every production account. Record technical severity, exposure, compensating controls, time to correct, and whether the required person or system transfers. The commercial conclusion should follow those facts.

Do not ask the seller to fix findings during the review unless the exposure demands immediate containment. Remediation can destroy evidence, distract the people needed for explanation, and make verification harder. Record the original state, agree on any urgent containment, and keep transaction assessment separate from the later repair program.

Team risk appears in work ownership

An organization chart does not show whether the acquired team can operate the product. Work ownership does. Map each essential activity to the people who currently perform it and to the evidence that someone else can take over: releases, incident command, database recovery, security administration, customer escalations, billing changes, and vendor renewals.

Single-person dependency is not automatically a deal breaker. It becomes expensive when the person will not transfer, the procedure is undocumented, access lives in a personal account, or the surrounding team cannot demonstrate the task. Buyers should distinguish rare expertise from preventable concentration. The first may justify retention terms; the second needs access cleanup, training, and an integration owner.

Interview the people who do the work, not only their managers. Ask an engineer to walk through the last failed release, an operator to restore a selected backup in a safe environment, or a support lead to trace a severe customer issue into engineering. Demonstrations expose handoffs and hidden tools that polished process descriptions miss. They also show whether the team learns from failure or depends on memory.

Headcount economics need the same care. A buyer may see automation and assume immediate payroll savings, or see a large backlog and assume more hiring. Both conclusions can be wrong. Separate maintenance load, roadmap work, customer commitments, operational toil, and integration projects. Then model which work disappears, which moves, and which grows after the transaction.

This is where I sometimes use the same evidence discipline from a Team & AI Audit at oleg.is: identify actual work, tool access, delays, and ownership before proposing a smaller or differently equipped team. The transaction still needs its own retention and integration judgment; an efficiency target cannot substitute for continuity.

Cost estimates need an operating baseline

Technology cost in diligence should describe the business the buyer will own, not repeat the seller's latest monthly bill. The reviewer must normalize unusual periods, assign shared expenses, expose commitments, and separate current operations from changes required by the acquisition plan. Without that baseline, savings and remediation estimates become negotiation positions rather than analysis.

Start by reconciling the general ledger, vendor list, cloud invoices, headcount roster, contractor spend, and architecture inventory. The totals rarely line up on the first pass. A cloud bill may include experimental accounts, credits, annual reservations, or services used by another business unit. The engineering roster may omit contractors who hold operational knowledge. A software subscription may cover the whole company even though only part transfers. Record each adjustment and who accepted it.

Then separate four cost types. Run cost keeps the current service operating at its present level. Growth cost supports the buyer's forecast. Remediation cost fixes a verified weakness. Integration or separation cost changes ownership boundaries after closing. Combining them hides the reason money is being spent. It also invites a buyer to count a necessary security repair as growth investment or to count an optional platform rewrite as unavoidable remediation.

Cloud efficiency deserves skepticism from both sides. Buyers often apply a broad savings percentage after seeing low utilization, while sellers point to discounts and claim the estate is already optimized. Neither claim is enough. Inspect workload schedules, reservation coverage, data transfer, storage growth, support tiers, and the labor required to change the architecture. A cheaper design that consumes a year of scarce engineering time may have a poor transaction return.

Estimate with explicit assumptions and ranges. State the systems included, the expected owner, outside services, licenses, migration overlap, testing time, and any downtime constraint. Show what would cause the range to move. If the team has not traced dependencies or tested a migration path, label the number as an order-of-magnitude planning figure rather than a budget.

Sellers shorten this work by providing invoice exports that reconcile to finance records and by mapping each major vendor to a system owner, contract term, renewal date, transfer right, and exit requirement. They should disclose credits and temporary discounts separately. A low current bill supported by expiring credits can mislead a buyer just as much as an inflated allocation from the parent company.

Keep planned savings outside the technical finding unless the buyer has named the system that will disappear and the date it can be retired. Duplicate tools do not create savings on closing day. Contracts, migrations, retention needs, data obligations, and team habits determine when spending actually stops. The diligence report should give decision makers a baseline they can change, along with the consequences of each change.

Findings must change a deal decision

The final report should connect every material finding to one of five actions: change valuation, change a representation or indemnity, add a closing condition, define a transition service, or fund a named post-close action. Findings that change none of these can move to an appendix or the integration backlog. This rule keeps technical curiosity from overpowering transaction judgment.

Write each finding as a compact argument. State the verified condition, cite the evidence reviewed, explain the business exposure, name what remains unknown, and recommend the decision action. Use ranges for remediation only when the scope and assumptions are visible. A precise number built on unknown architecture is less honest than a bounded estimate with explicit exclusions.

The buyer should also record limitations. If reviewers lacked production access, could not interview a departing architect, sampled only one region, or received incident data for a short period, say so beside the affected conclusion. Limitations are not disclaimers to hide at the back. They tell the investment committee how much confidence to place in the answer.

Sellers should correct facts with evidence and resist arguing about labels. Whether a buyer calls an issue high or medium matters less than whether both sides agree on the affected system, exposure, remedy, and cost bearer. A short factual response with a current artifact can close a finding. A long response about why the label feels unfair usually consumes another day.

Two weeks works when both sides enter with a decision map, live access, named owners, and permission to surface bad news. Four weeks is the honest choice when the buyer must reconstruct the system or price a separation. Set that boundary before kickoff. Otherwise the deal will spend its first week discovering that the timeline was never real.