I’ve led or participated in technical due diligence for 15+ acquisition transactions. The pattern is consistent: buyers spend weeks analyzing code quality, architecture, and technical debt. They produce detailed reports rating technology stacks and identifying technical risks.

Then the acquisition closes and the actual problems emerge — deployment process incompatibility, monitoring gaps, security practice mismatches, and team cultural conflicts that the due diligence barely touched. The code quality concerns identified during diligence often turn out to be manageable. The operational and organizational issues that weren’t examined thoroughly derail integration.

Technical due diligence that focuses primarily on technology stacks and code architecture is looking in the wrong places. The determinants of post-acquisition technology integration success are operational maturity and team dynamics, not whether the target company uses React or Vue.

What Traditional Due Diligence Examines

Standard technical due diligence covers:

Technology stack assessment. What languages, frameworks, databases, and cloud platforms does the target use? Are these compatible with acquirer’s standards? How much replatforming work is required?

Code quality analysis. Automated analysis of code repositories for technical debt indicators — code complexity, test coverage, dependency freshness, security vulnerabilities.

Architecture review. System design documentation, service boundaries, data flows, integration patterns. Is the architecture sound? Does it scale? Are there obvious design problems?

Intellectual property verification. Does the company own what it claims? Are there license compliance issues? Are there legal risks from open source usage?

Security assessment. Vulnerability scanning, penetration testing (if time permits), review of security practices and incident history.

These aren’t unimportant. But they’re also not the primary sources of post-acquisition pain in most technology acquisitions I’ve seen. The problems that cause months of delay and millions in remediation costs usually come from areas that traditional due diligence treats as secondary concerns.

What Actually Matters: Operational Maturity

The operational practices gap between acquirer and target creates most integration friction.

Deployment and release process. How does the target company deploy code? If the acquirer does automated CI/CD with comprehensive testing and the target does manual deployments with spot-checked QA, integrating development processes will be painful. This isn’t about code quality — it’s about workflow compatibility.

Monitoring and observability. What visibility does the target have into production systems? If the acquirer has comprehensive APM, distributed tracing, and structured logging while the target has basic server monitoring and ad-hoc logs, post-acquisition incident management becomes difficult. You can’t operate what you can’t observe.

Disaster recovery and business continuity. Does the target have tested backup and recovery procedures? When was the last time they attempted a restore? If this hasn’t been verified before acquisition, you’re buying unknown risk that only manifests during actual incidents.

Security operations. Not penetration testing or vulnerability scanning — actual security operations. Does the target have security response procedures? Vulnerability management processes? Access control auditing? Gaps here create immediate post-acquisition work.

On-call and incident response. Who gets paged when things break? How quickly do they respond? What runbooks exist? If the target has informal incident response while the acquirer has structured SRE practice, integration requires either bringing target systems to acquirer standards (expensive) or maintaining separate on-call pools (problematic).

Compliance and audit requirements. If the acquirer is subject to SOC 2, ISO 27001, or industry-specific compliance while the target isn’t, bringing target systems into compliance is often underestimated work. This should be priced into the acquisition, but often isn’t discovered until post-close.

The Documentation Problem

The state of operational documentation predicts post-acquisition pain better than code quality metrics.

Runbooks for common operations. How do you deploy? Scale capacity? Rotate credentials? Perform database migrations? If this knowledge lives in individual people’s heads, losing those people during acquisition transition creates immediate capability loss.

Architecture decision records. Why were specific technical choices made? What tradeoffs were considered? Without this context, the acquirer may undo carefully-considered decisions because the reasoning isn’t documented.

Disaster recovery procedures. Step-by-step documentation for restoring service after major failures. If this doesn’t exist or hasn’t been tested, you’re buying systems you can’t reliably operate.

Access inventory and dependency mapping. What systems exist? How do they interact? What external services are dependencies? Complete inventory seems basic but missing or incomplete inventories are common.

I’ve worked with specialists in this space who emphasize that documentation gaps are signal of operational maturity gaps. Organizations with mature operations document systematically. Organizations without documentation often lack the operational rigor documentation would reveal.

Team Dynamics and Knowledge Concentration

Several people-related factors predict post-acquisition problems:

Key person dependencies. If critical knowledge resides in one or two people, their retention becomes essential. Due diligence should identify these dependencies explicitly. Losing a key engineer post-acquisition creates operational risk that affects system valuation.

Team distribution and time zones. Remote teams across many time zones create coordination challenges. If the acquirer operates in AEST and the target team is distributed across US time zones, incident response and collaboration become complicated. This affects operational continuity.

Development team vs operations team split. Is there clear operational ownership? If “development teams” build features but nobody has defined operational responsibility, post-acquisition incident management becomes chaotic. Who gets paged? Who fixes production issues?

Communication patterns. How does the target team communicate and make decisions? Synchronous vs asynchronous, Slack-heavy vs meeting-heavy, documented decisions vs hallway conversations — these cultural practices affect integration more than tech stack choices.

What Code Quality Actually Tells You

Code quality analysis isn’t useless — it’s just not as predictive as buyers assume.

Test coverage numbers lie. 80% test coverage doesn’t mean the tests are good or that they test important behaviors. Low coverage often matters less than buyers expect because if the system works in production, test gaps haven’t prevented successful operation.

Technical debt is manageable. Most code bases have technical debt. What matters is whether the team understands their technical debt and has a remediation plan. A messy code base with conscious technical debt is often better than a “clean” code base where the team doesn’t recognize architectural problems.

Framework/language choice rarely matters. Buyers often worry about technology stack differences — “they use Python and we use Java” or “they’re on Postgres and we’re on MySQL.” These differences are engineering problems with known solutions. They’re not the source of integration failure.

The exception is when technology choices reveal operational maturity. A company running unsupported PHP 5.6 in production isn’t just making a technology choice — they’re demonstrating failure to maintain basic operational hygiene. That’s a signal worth paying attention to.

Due Diligence Questions That Actually Matter

Based on painful post-acquisition experience, here’s what I now ask during technical due diligence:

Operational questions:

• How do you deploy to production? Walk me through the process.
• When was your last production incident? How did you respond?
• How do you monitor production systems? Show me your dashboards.
• What’s your disaster recovery RTO and RPO? When did you last test recovery?
• How do you manage secrets and credentials? Show me your rotation process.

Knowledge and documentation questions:

• Where is system architecture documented? Show me examples.
• If your lead engineer left tomorrow, how would knowledge transfer work?
• What runbooks exist for common operational tasks?
• Where are architectural decisions documented?

Team and process questions:

• How do you decide what to build?
• How do code changes get reviewed and deployed?
• Who has production access? How is access granted and audited?
• How does cross-team communication happen?
• What’s your on-call rotation and escalation process?

These questions reveal operational maturity and team health in ways that code analysis can’t.

Red Flags That Predict Problems

Several patterns consistently predict difficult post-acquisition integration:

“We’ve never had a major production incident.” Either they’re incredibly lucky, they don’t monitor closely enough to notice incidents, or they’re not being honest. All production systems have incidents. Claiming otherwise signals operational immaturity or dishonesty.

Tribal knowledge culture. Key operational knowledge isn’t documented because “everyone knows how it works.” This indicates future knowledge loss risk when people leave post-acquisition.

Hero culture. “John always fixes production issues.” This signals single point of failure and lack of repeatable operational processes.

No staging or test environments. “We test in production.” This might work for a small startup, but it’s a risk that will cause problems at scale post-acquisition.

Undefined security responsibility. When you ask who’s responsible for security, answers like “everyone” or uncertainty about who responds to security issues signal immature security operations.

The Bottom Line

Technical due diligence should spend less time analyzing code quality and more time understanding operational maturity and team dynamics. The code will get refactored eventually. The operational gaps will cause immediate post-acquisition pain.

Acquisitions succeed when the target company has mature operations, documented processes, and healthy team dynamics — even if the code isn’t perfect. Acquisitions struggle when operational practices are informal, knowledge is concentrated in a few people, and processes aren’t documented — regardless of code quality.

Due diligence that focuses on what’s easy to analyze (code metrics, architecture diagrams) while under-examining what’s harder to quantify (operational maturity, team health) systematically underprices operational risk and overweights technical debt that’s actually manageable.

The most valuable technical due diligence I’ve seen spends half the available time talking to engineers about how things actually work, reviewing operational runbooks and incident response procedures, and understanding team dynamics. The other half analyzing code is useful validation, but it’s not where the determinants of post-acquisition success or failure live.