Software technical due diligence: evidence for a decision, not a verdict on the code

OutsourcingVN is operated by Netbase JSC, which sells technical audit sprints and would gladly run this review for you, so read the method as a supplier's method. It works with any reviewer. It draws on two Netbase records: the scoped recovery of a compromised Magento store, whose first phase is an investigation, and a Magento 1 to Magento 2 migration.

When do you need technical due diligence?

You need it whenever a commitment would be expensive to reverse and the system is the thing being bought, funded or inherited. Typical triggers are acquiring a company whose value sits in its software, investing in a product business, choosing a vendor platform you will extend for years, and deciding whether a failing build is worth finishing. Due diligence happens before the commitment. Once the decision is made and the system is yours, the work changes into a transfer, which the software takeover and maintenance guide covers step by step.

What should the review examine?

Include an area only if a finding there could change the decision, and ask for evidence rather than descriptions.

The legacy system risk assessment goes deeper on old platforms, and the data security and compliance guide lists the access questions to settle before a reviewer sees production data.

How should findings be rated?

Rate each finding by what it means for the commitment, not by how untidy the code looks.

Worked scenario: an acquirer reviewing a quoting product

A regional logistics group plans to acquire a small company whose web product produces freight quotes for shippers. The deal team allows ten working days for technical review, and the decision question is whether the product can be integrated with the group's customer portal within a year.

• Days 1-2. The reviewer logs evidence. The main repository sits under the founder's personal account, and the cloud account is billed to the founder's card. Rated condition before signing.
• Days 3-4. A clean-checkout build fails because a private package lives only on one developer's machine. The developer supplies it; the build succeeds. Rated post-close remediation, with a note that the release process depends on one person.
• Day 5. A backup is restored in a test environment. It works but takes most of a day. Rated accepted risk with a review date.
• Days 6-7. Interviews show that the quote rules engine was written by a contractor who has left, and only the founder understands it. Rated condition before signing: two recorded knowledge-transfer sessions before close.
• Days 8-10. The report states that the integration question is answerable: the product exposes an API that the portal can call. It lists what was not inspected, including mobile builds and load behaviour.

The group signs with three conditions and a separate remediation scope.

What do Netbase records show about inspection before scope?

For an existing client store, Netbase scoped a three-phase recovery of a compromised Magento site. The first phase is investigation: a security scan with cause analysis, a full source-code and database malware scan, server log, permission and abnormal-file checks, and a damage assessment, delivering an infected-file report and a recovery plan. Cleaning and hardening come only after that report. The whole recovery typically takes 6 to 13 days depending on the damage, and it carries no guarantee of full recovery. The Magento recovery and hardening record shows how an evidence phase sets the scope of everything after it.

For Netztech, Netbase delivered a Magento 1 to Magento 2 Commerce migration in 35 working days, including migrating 11 extensions with installation, configuration, customization and data transfer. The Netztech migration record shows why a due-diligence inventory must list every extension and data store: each one becomes a line of migration scope.

Which questions should you ask the reviewer?

• Which decision will your report support? A good answer restates your question and says what the report will not decide.
• What access do you need, and can it stay read-only? Expect read-only by default and a named reason for any exception.
• Who will hold access, and under what agreements? At Netbase, security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
• Which roles will do the review? Netbase project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles; a due-diligence review usually needs architecture and security depth first.
• Is the report a certification or an attestation? It should not be presented as one. Netbase JSC holds ISO 27001 certification for information security management; that is the company's own certification and never extends to a system Netbase reviews.
• How will you rate findings? Look for a scale tied to the decision, like the one above.
• Will you bid for the remediation? A reviewer who might win the follow-on work has a conflict; ask for it to be disclosed.
• What will you record as not inspected? A report without that section overstates its own coverage.

What goes wrong in due diligence?

• Reviewing the demo, not the system. Signal: the seller controls the environment you see. Owner: the deal lead, who insists on repository and production evidence.
• No clean build. Signal: "it builds fine here". Owner: the reviewer, who treats an unreproducible build as a finding.
• Findings without ratings. Signal: a long list and no recommendation. Owner: the reviewer, who must map each finding to the decision.
• Remediation slipping into the review. Signal: the reviewer starts fixing. Owner: the buyer, who keeps fixing as a separate project so the finder does not mark their own repair.
• Forgetting operations. Signal: nothing is said about who runs the system after close. Owner: the operating lead, who plans the post-close arrangement with the managed software operations scope guide.

How this guide is sourced and where it stops

This guide combines public secure-development references with Netbase records approved in the OutsourcingVN claim register: the scoped Magento recovery, the Netztech migration, security practices, team roles and the company's ISO 27001 certification. The methodology explains how those records are sourced. Netbase has no published record of a due-diligence engagement for an acquisition or investment, so this page describes a method, not a track record in that setting. It covers technical risk only; legal, financial and tax review belong to other advisers.

Bring your decision question

Start with the question, the date it must be answered and the access you can arrange. A technical audit sprint is the bounded review route; after close, Managed Operations covers running the system, and the release readiness checklist helps the first change after close go out safely.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with the decision question and the systems in scope, and a person will reply with whether a bounded review can answer it.

Related services and solutions