Review SaaS isolation, recurring revenue dependencies, operating costs and integration risks. Connect technical evidence to the acquisition plan.
A SaaS acquisition transfers an operating service, not merely a codebase. The buyer inherits customer commitments, infrastructure dependencies, release practices and people who know how failures are repaired. Technical due diligence should test the assumptions behind the acquisition plan: can the service be operated, integrated and developed with the available team and investment? Define those assumptions before requesting repository access.
Trace one tenant through the service
Follow onboarding, access, billing, data processing, support and offboarding. Identify where tenant context is enforced and how privileged support access is controlled. Inspect a representative sample of background jobs, exports and integrations as well as interactive requests. These paths often have different ownership and access assumptions. Record which conclusions come from code review and which were demonstrated in an agreed environment.
| Acquisition question | Evidence to inspect | Potential follow-up |
|---|---|---|
| Can we operate the service independently? | Account ownership, access recovery and supplier dependencies | Transfer plan and operating rehearsal |
| Does growth improve or harm unit economics? | Workload-specific costs and shared infrastructure allocation | Capacity and cost model with explicit assumptions |
| Can we retain customer commitments? | Architecture constraints, support arrangements and recovery evidence | Plan for material gaps and transition coverage |
| Can products be integrated safely? | Identity, data models and API contracts | A limited integration experiment before broad consolidation |
Reconcile technical and commercial narratives
Ask how subscription state becomes application access, how cancellations and failures are handled and how usage is attributed. Technical evidence does not replace financial diligence, but it can expose dependencies in revenue operations. Likewise, a low current cloud bill does not prove that costs scale well; identify manual work, shared accounts and infrastructure subsidised outside the reported boundary.
Plan the first operating period
List the people, permissions and recurring tasks needed immediately after transfer. Identify knowledge concentrated in one person and establish a documented handover. Distinguish urgent continuity actions from longer-term architecture improvements. A large rewrite may conflict with the acquisition’s retention goals, while a narrow compatibility layer may support integration with less disruption.
- Record the investment thesis as technical questions with evidence owners.
- Sample the full tenant lifecycle, including administrative and asynchronous paths.
- Compare transfer dependencies against the planned completion date.
- Produce an integration risk register with acceptance checks and unresolved assumptions.
The conclusion should explain where the evidence supports the plan, where additional investment is likely and what remains unknown. Avoid treating technology preferences as acquisition blockers unless they create a concrete operational or strategic constraint.
- Technical due diligence
- Multi-Tenant SaaS Architecture: Isolation and Trade-Offs
- Technical Due Diligence Data Room: Documents to Prepare
Frequently asked questions
Is source access enough for SaaS diligence?
No. Operating records, infrastructure ownership, billing dependencies and interviews help assess whether the service can be maintained and transferred.
Should we test tenant isolation?
Include an agreed assessment proportionate to the risk. Distinguish code evidence, configuration review and authorised runtime verification in the report.
Can technical diligence validate revenue?
It can examine the systems supporting billing and access. Financial and commercial verification remain separate disciplines with their own evidence.
Should the buyer immediately rewrite the platform?
Only after evaluating the actual constraints, retention risk and integration goals. A staged improvement may fit the acquisition better.
What is a useful post-acquisition deliverable?
A continuity and integration plan naming critical access, people, dependencies, risks and the evidence required to close each priority action.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
Multi-tenant SaaS architecture: isolation and trade-offs
Compare pooled and separated tenant architectures across data, jobs, storage and operations. Make tenant isolation explicit instead of relying on login alone.
Technical due diligence data room: prepare useful evidence
Prepare a technical data room with an indexed inventory, controlled access and evidence owners. Reduce repeated questions without exposing unnecessary secrets.
Technical due diligence cost: scope, timing and deliverables
Understand what changes technical due diligence effort. Compare proposals by systems, evidence, access, transaction questions and the depth of the final report.