Legacy Health Check: Scope and Deliverables

Which decision does a software health check support?

Find the part holding your business back before choosing maintenance, renewal or integration. A health check brings business rules, dependencies and the first modernization step into a plan you can assess.

The planning range is 1–2 weeks. Timing depends on access to code and environments, application boundaries and the required interviews. The schedule is agreed after discovery. The assessment is quoted as a fixed-price scope once the application and access conditions are understood.

Which questions does the assessment answer?

• An undocumented desktop application → critical workflows, data ownership and a dependency map.
• A difficult-to-maintain PHP, .NET or Java application → a scoped review of versions, dependencies and change risks.
• Scattered database knowledge → data relationships, access boundaries and questions a migration must answer.
• Competing renewal ideas → priorities, cost assumptions and options divided into manageable stages.

Unavailable code, inaccessible environments and unconfirmed business rules remain explicit open questions. The report compares retaining the system, changing a specific part and undertaking a broader migration.

How is the assessment carried out?

1. Define scope and access: agree which application, environments and sample data are included, with permissions and sharing conditions.
2. Interview workflow owners: record critical tasks, exceptions and other processes that rely on the application.
3. Review the technical system: assess code structure, dependencies, data relationships, releases and restore procedures within scope.
4. Compare options and costs: examine retention, renewal of a specific part and a broader migration, with their assumptions.
5. Review the report: discuss evidence, priorities, uncertainty and acceptance criteria for a possible next stage.

What does the report include?

• Dependency and risk map: components, external services, ownership, reasons for each risk and the scope of inspection.
• Code and business-rule documentation: critical flows, data relationships and behaviour awaiting confirmation.
• Cost model: current expenses, potential investment items, scenario assumptions and missing inputs.
• Staged roadmap: prioritized work packages, dependencies, acceptance criteria and decision points.

The report distinguishes measurements, observations and assumptions. The methodology page explains how evidence is presented. Cost, security and continuity objectives can guide the assessment’s priorities.

Frequently asked questions

Is delivery within 1–2 weeks guaranteed?

No. It is a planning range. Access readiness, scope and the availability of relevant people affect the schedule. The start date, review points and delivery conditions are agreed in the proposal.

Can an assessment be prepared without source code?

A limited assessment may be possible using available documentation, external interfaces and user workflows. Anything that cannot be verified without code is stated explicitly. The result is not presented as a completed source-code review.

Is this a penetration test or a security certificate?

No. In-scope security findings and dependency risks are recorded. Work requiring a separate test is identified as a recommendation. The report is neither a compliance certificate nor an assurance that the system is fully secure.

Do you need access to production?

The aim is to obtain the necessary information with limited access. If documentation, configuration summaries and a suitable test copy are sufficient, production access is not requested. Required permissions and data sharing are agreed before work starts.

Must you carry out the implementation after the assessment?

The report is a decision and planning deliverable. Implementation is a separate scope and quote. Assumptions and open questions remain visible so that your own team or another supplier can evaluate the plan.