A legacy software assessment should establish what the application does, how it is operated, and which changes can be made with acceptable risk. Age and programming language are insufficient reasons to replace a system. Focus on the business capabilities that are hard to maintain or extend and the evidence needed to improve them.
The immediate outcome is a prioritized action plan. A complete rewrite is one possible conclusion, not the starting assumption.
Gather evidence in six areas
| Area | Evidence to request | A useful verification |
|---|---|---|
| Build and release | Repositories, dependency sources, build instructions | Produce a runnable build in a clean environment |
| Business behavior | User journeys, calculations, exception rules | Reproduce a representative operation with its owner |
| Connections | Incoming and outgoing interfaces, scheduled jobs | Trace one record through its dependencies |
| Data | Ownership, size, constraints, exports, backups | Restore a sanitized copy and check key relationships |
| Operations | Monitoring, incidents, access, deployment history | Walk through recovery with the people on call |
| Change confidence | Automated tests and acceptance examples | Modify a small behavior and detect a deliberate regression |
Record missing evidence as a risk with an owner. “The previous developer probably knows” is an unresolved dependency.
Distinguish symptoms from constraints
Slow delivery might come from an unreliable test environment, unclear approval responsibilities, or a tightly coupled application. Each suggests a different intervention. Interview users, maintainers, and infrastructure owners before attributing every problem to the codebase.
For a hypothetical order-processing system, new pricing rules may take weeks to validate because expected results are undocumented. Capturing approved calculation examples could improve change safety before any architectural replacement begins.
Find a boundary for the first change
Look for a capability with a clear input, output, and owner. Assess how requests can reach the replacement and where data is written during the transition. Avoid calling a change independent when several other systems write directly to its tables.
Microsoft’s Strangler Fig pattern describes gradually routing functionality from an existing application to replacement components. It provides an architectural option; your assessment still needs to establish whether the application has suitable boundaries.
Turn findings into an actionable register
For each finding, record its business consequence, supporting evidence, confidence, possible intervention, dependency, and owner. Separate urgent operational risks from improvements that can wait for related feature work.
An example entry might read: “Restore procedure has not been rehearsed; recovery duration is unknown; operations owner will perform a test restore before the next major release.” That is more actionable than “backup process needs improvement.”
What should the final recommendation contain?
Request a current-system map, a verified build and recovery status, a ranked risk register, and a first-change proposal with acceptance and rollback criteria. Note any areas the assessment could not inspect.
Use the modernization-versus-rewrite guide to compare delivery options once the evidence is available. A narrow, tested intervention can be a better first investment than an extensive roadmap built on unknowns.
Put it into practice.
Explore our software modernization services service or send us the problem you are working on.