Software Architecture Due Diligence for an Acquired Product
What will the buyer inherit?
Business obligation → inspected evidence → bounded finding → receiving owner → closure evidence
Software architecture due diligence for an acquired product should answer whether the buyer can operate, change and recover the product under the ownership arrangement being considered. The useful output is an evidence register tied to business obligations and post-close actions. A diagram of services or a count of outdated packages cannot answer that question on its own.
Start with the obligations the acquisition would transfer. Then connect each material concern to an observed artifact, the limits of that observation and a named receiving owner. Keep unanswered questions visible. A missing recovery demonstration is an evidence gap until further inspection establishes a defect; it is not proof that recovery will fail.
This guide provides a proposed review method and an unfilled register. No acquired product, private repository or customer environment was inspected for this article. The requests below describe work a properly authorized team can commission. They do not report completed tests, acquisition findings or a recommendation to complete a transaction.
Define the acquisition question before requesting evidence
An acquisition review needs a boundary that matches the proposed transaction. Identify the product, customer obligations and operating assets in scope. Record which repositories and environments support them. A product name may cover several deployments with different ownership arrangements. A repository bearing that name may contain only the customer-facing interface.
Ask the deal team which assumptions could change the integration plan. Continuing the product independently requires different evidence from moving its customers into the buyer's existing platform. The review should explain the implications of each stated operating intention without pretending that the final commercial decision belongs to the architect.
Separate technical evidence from rights and contractual interpretation. Engineers can inventory dependencies and identify where an external service is required. Qualified legal and commercial reviewers determine whether the relevant agreement permits the proposed transfer or continued use. A working integration does not establish that a contract is assignable.
Agree on permitted access before collecting material. Read-only repository access and supervised demonstrations may answer early questions. Production changes, recovery exercises and customer-data exports need their own scope and authorization. Establish where review evidence may be stored and who can see it. Due diligence should not create an uncontrolled second copy of confidential operating data.
Give every request a decision purpose. Request a release record to identify the relationship between reviewed code and deployed behavior. Request a recovery record to establish what the team actually restored. An unrestricted request for all engineering documents often produces volume without resolving the buyer's most consequential uncertainty.
Set a review date and a cutoff for changes. Record later releases or infrastructure changes that could invalidate earlier observations. If a material deployment occurs after the inspection, identify which conclusions require renewal. A report should describe the assessed version rather than silently presenting an earlier snapshot as the closing state.
Trace a business obligation through the architecture
Choose a business path whose interruption would matter to the acquisition thesis. Trace its entry point through the application and persistent state to any external effect. Identify the component responsible for deciding that the operation succeeded. Include background work that continues after the customer receives a response.
The official C4 model separates architecture views through hierarchical abstractions and supporting diagrams. Use that separation to keep the system boundary readable before inspecting individual components. A context view can establish external actors; a deployment view can locate runtime dependencies. Neither substitutes for evidence that the deployed implementation matches the picture.
For each important connection, request the enforcing mechanism and its operating owner. An arrow labeled authentication should lead to the actual identity boundary and configuration evidence. An arrow labeled asynchronous should identify where outstanding work is held and who resolves it after a failure. Unnamed arrows conceal obligations that a buyer may inherit.
Compare the map with available configuration and deployment records. Mark a connection confirmed only within the inspected scope. A seller explanation can be useful evidence of intended design while remaining distinct from an observed configuration. Preserve disagreements between sources rather than redrawing the diagram until every line appears consistent.
Follow administrative paths too. Customer support tools, scheduled exports and repair jobs may modify the same records as the primary application. A buyer who understands only the public request path may overlook the mechanism operators use to correct or resume work. Ask what permissions those tools require and how their actions are recorded.
Document important exclusions beside the map. If a regional deployment, legacy customer group or reporting subsystem was not inspected, state that directly. Avoid conclusions about the whole product from one well-understood path. The next inspection should be chosen because it resolves a material uncovered obligation, not because another diagram would make the report look comprehensive.
Establish whether the reviewed product can be released
Ask the team to identify a deployed release and its originating source revision. Follow the release record through the build process to the artifact actually deployed. Retain identifiers that another reviewer can use to repeat the trace. A screenshot of a successful pipeline does not necessarily identify the artifact serving customers.
Determine which inputs the build requires beyond the main repository. These can include private packages, generated assets and configuration supplied through a separate system. Record the owner of each required input and its availability under the planned operating arrangement. Successful builds on an existing employee's laptop do not establish independent reproducibility.
An authorized clean-environment demonstration can reveal missing assumptions. Define what counts as clean, what external resources remain available and which steps the operator may perform manually. Record the procedure and actual result. If the demonstration is unavailable within the review window, retain that limitation instead of converting a written instruction into a successful test.
Inspect the release authority separately from build capability. Identify who may approve deployment, how privileged credentials are obtained and what prevents an unintended artifact from being promoted. The buyer needs to know whether these controls reside in transferable organizational systems or depend on accounts outside the proposed boundary.
Ask how a failed release is handled when it changes persistent state. Returning an application binary to its earlier version may leave a schema or queued message that version cannot understand. Request evidence for the relevant compatibility assumptions. A rollback button is an interface to a procedure, not evidence that every affected business operation can return safely.
Record manual steps without automatically treating them as defects. A deliberate approval can be appropriate. An undocumented command known only to one person creates a different dependency. Describe the consequence of losing that knowledge and the evidence needed to transfer it. The proposed action may be a documented procedure and rehearsal rather than a new deployment platform.
Review data authority and recoverability together
For material records, establish which system is authoritative and which systems hold copies or projections. Ask how the product distinguishes accepted work from work awaiting completion. That distinction matters when a receiving team must recover service without silently losing an obligation or applying the same external effect twice.
Request a current backup inventory and the procedure that uses it. Include the data stores required by the selected business path and the keys or configuration needed to interpret them. A database backup can be present while an unavailable encryption key prevents its use. Record those dependencies explicitly rather than treating backup existence as a complete recovery result.
A recovery demonstration needs an acceptance condition. Define the environment, restored data boundary and observable business result before the exercise begins. Retain the selected recovery point and actual completion evidence. Do not declare a target met merely because a process finished without an error message; the recovered application may still lack required state.
Inspect what happens to work outside the restored database. Messages, external-provider operations and downstream exports may have advanced independently. The review should identify how operators reconcile those boundaries. Restoring an earlier local snapshot does not reverse a provider's accepted instruction or a report already delivered to a customer.
Ask which people can explain an uncertain result. Google SRE's Effective Troubleshooting, written by Chris Jones, states: Knowledge of the system typically limits the effectiveness of an SRE new to a system
. The passage supports examining system knowledge during transfer. It does not establish that any particular acquired team has a knowledge deficit.
Keep observed recovery evidence separate from intended service objectives. The report may retain an objective supplied by the product owner and a narrower exercise result. Explain the difference. If the test excluded a dependency, state which additional inspection would be required before relying on the objective for the complete business path.
Convert security assertions into bounded verification requests
Security review begins with the assets and actions that matter to the acquired product. Identify privileged interfaces and the identities that can change important state. Include service accounts and emergency access. An organizational chart rarely reveals all the privileges attached to automation or support workflows.
The OWASP Application Security Verification Standard provides a basis for technical security requirements and testing. Its current official site identifies version 5.0.0 and recommends versioned requirement references. Use an agreed version and applicable scope when requesting evidence. Mentioning the standard does not establish that a product has passed its requirements.
For a selected control, retain the tested build and relevant conditions. An authentication failure observed before a protected action was reached may establish that the session was rejected, but it cannot alone establish the authorization behavior of the intended action. The review must connect the observation to the specific assertion it is meant to support.
Request unresolved findings together with disposition evidence. A ticket marked fixed describes a workflow state. Verification needs evidence that the relevant condition was exercised after the change. If a finding was accepted rather than corrected, identify the responsible decision and its scope without assuming that the buyer inherits the same risk acceptance.
Inspect how access changes when ownership changes. Determine which identities are organizational, which belong to suppliers and which depend on individuals remaining involved. Plan the transition so necessary operations remain available while former access is closed at the agreed point. Do not treat possession of an exported password list as an acceptable transfer procedure.
Avoid publishing vulnerability details in a general deal summary. Keep sensitive proof in the approved evidence location and reference it through controlled identifiers. The decision memo needs enough information to explain business consequences and required actions. It need not reproduce credentials or exploitation instructions to demonstrate that the reviewer understood the concern.
Identify dependencies the buyer would have to retain
Build a dependency inventory around continued operation and change. Include infrastructure providers, private artifact stores and support services that are necessary for the reviewed paths. Connect each dependency to its function and owner. A package inventory is useful, but it does not describe every commercial or operational dependency.
For software components, record the actual version and where it is used. Distinguish a development dependency from a component that processes customer requests. Ask how the team learns about updates and decides whether a change is required. A list of old versions should lead to an impact assessment rather than an automatic rewrite recommendation.
Provide rights reviewers with the component and contract evidence they need. Preserve source provenance and available license records. Flag missing or conflicting records as questions for the responsible specialist. Engineers can explain how a component is linked or distributed; the legal conclusion belongs to the reviewer authorized to make it.
For external integrations, identify the identity and agreement under which requests are made. A sandbox demonstration may not establish access to the production service after close. Ask which onboarding or approval steps the proposed owner must complete. Record unknown timing as an uncertainty rather than inventing a procurement lead time.
Consider the consequences of a dependency becoming unavailable. Identify what remains readable and which operations must stop. Request evidence for export or replacement procedures where they matter to continuity. A vendor's documented export feature does not establish that the acquired product has tested a usable export of its own required records.
Preserve the distinction between retention and replacement. Continuing with an existing service can be a reasonable operating choice while the buyer resolves a transfer question. Replacing it may require separate engineering and business acceptance. The diligence report should expose the decision and its dependency, not quietly embed a preferred technology migration into the acquisition plan.
Use an evidence-to-action register with explicit gaps
The following register is a blank working structure. It contains requests and decision rules, not findings from a transaction. Populate it only with material actually reviewed. Each row should identify the evidence version and the person responsible for the next action. Unavailable evidence remains unavailable until a new observation changes that status.
| Review area | Evidence to request | Question for the buyer | Action if unresolved |
|---|---|---|---|
| Release provenance | Deployed artifact and source trace | Can the reviewed code be connected to the operating product? | Retain the gap and request a bounded trace demonstration |
| Recovery | Restore record with business acceptance | Which obligations can resume from the demonstrated state? | Limit reliance to the observed scope and assign further inspection |
| Privileged access | Identity inventory and transition procedure | Can operating authority transfer without orphaned privileges? | Assign a receiving owner and an authorized transfer rehearsal |
| External dependency | Function, agreement reference and operating identity | Is continued operation supported under the proposed arrangement? | Route rights questions to the appropriate reviewer |
| Security finding | Original condition, change and verification evidence | What assertion does the latest observation actually support? | Keep the unresolved condition visible in the decision memo |
Use distinct statuses for evidence availability and the underlying technical condition. Not inspected, inspected with limitations and corroborated within scope describe knowledge. A demonstrated defect describes behavior. Combining those categories in one red or green cell can make an unknown look like a failure or an unsupported assertion look like a pass.
Write the finding narrowly. Identify the artifact inspected, what it showed and what it did not show. Then connect the observation to a business consequence under the stated acquisition plan. If that consequence depends on an assumption, name the assumption and its owner. This makes disagreement reviewable without hiding it inside a severity label.
Assign post-close actions to receiving roles that have accepted the work. A task without access or budget is not a credible mitigation. Record prerequisites and the evidence needed to close the action. Keep a seller clarification separate from the buyer's acceptance that the response resolves the question.
Avoid adding unrelated estimates as if they were measured facts. Repair effort requires a defined scope and uncertainty range supported by an actual review. Where that work has not occurred, request a scoped estimate. A diligence report can identify the need for investment without fabricating a delivery date or assigning a universal cost to technical debt.
The register should survive the report handoff. Maintain links to the controlled evidence and retain prior observations when a row changes. A later successful test can narrow an earlier concern, but it should not erase the record of what the acquisition team knew when it made a decision. Preserve the decision date alongside the later closure evidence.
A useful closure request names the missing observation rather than asking the seller to reassure the buyer. Request the release identifier that links the inspected source to the running application. Request the record that shows a restored business operation reaching its accepted state. Specify which part of the question remains open if the requested evidence cannot be produced. This keeps an incomplete response from becoming an implied approval.
Track evidence freshness at the assertion level. A new deployment may affect release provenance without changing the contractual dependency inventory. A change in identity ownership may affect access transfer without altering the application build. Renew the affected observations instead of either accepting every older artifact or demanding that the entire review restart. Record the reason an earlier observation remains applicable when its surrounding environment changes.
Review contradictory evidence with the people responsible for its source. An architecture document and a deployment record may describe different versions or different customer populations. Determine whether their scopes differ before classifying either as wrong. Retain the source dates and the explanation in the register. If the contradiction remains unresolved, restrict the conclusion rather than selecting whichever artifact supports the preferred deal narrative.
Deliver a decision memo and an operating handoff
The decision memo should state what was assessed and which acquisition assumptions it used. Lead with the obligations the buyer can rely on within that evidence boundary. Then describe material unresolved questions and the actions required to resolve them. Keep the inspected product version visible so readers do not mistake the memo for a permanent certification.
Separate transaction decisions from engineering recommendations. The review may identify an unresolved transfer dependency that the deal team must address before relying on a particular operating plan. It may also identify maintenance work that can be scheduled after close. Those consequences need different owners even when they originate from the same technical observation.
For teams commissioning this review, Pharos Production's architecture review and software engineering services provide a relevant starting point for scoping the technical work. Ask for an evidence register and a receiving-team handoff tied to the product under review. The published service scope supports that conversation; it does not establish that any acquisition was inspected or that a transaction should proceed.
Make the initial operating plan executable by the receiving team. Identify who receives alerts and who can authorize an emergency change. Confirm access through the agreed transfer procedure. Schedule unresolved knowledge transfer against specific operating tasks, such as interpreting a queued operation or identifying the deployed release, rather than treating attendance at a presentation as acceptance.
Preserve the seller's explanations with their limits. An experienced engineer may supply essential context that is not yet captured elsewhere. Record the explanation and connect it to the next verification step. The buyer should be able to distinguish an explanation it understands from a procedure its team has demonstrated independently.
Close each material question with one of three outcomes: evidence supports the stated operating assumption, a named limitation remains accepted by the responsible decision-maker, or further evidence is required. Do not manufacture a single maturity score to average these different outcomes. The acquired product becomes more understandable when the buyer can trace each consequential decision back to its evidence and next owner.
Comments
Post a Comment