Practical guide
How to assess a legacy application
Recover behavior, data, dependencies, operations and quality before selecting a modernization target.
Page purpose
Use How to assess a legacy application to resolve a specific decision, not as a generic information list.
A legacy assessment should recover enough evidence about behavior, data, dependencies, operations, controls, and changeability to support a specific decision. Age or technology choice alone does not determine whether to retain, contain, reshape, replace, or retire.
Assessment depth must reflect criticality and uncertainty. A short review can triage a low-impact tool; a mission-critical application with hidden rules and direct data access needs deeper observation and testing.
Decision trap
The ambiguity this guide is designed to remove.
- Documentation is outdated and important knowledge remains with a few operators.
- Proposals assume the source code describes all current business behavior.
- Dependencies are discovered only when a change or outage affects another process.
- Support, security, licensing, and recovery risks are discussed without evidence.
Comparison criteria
Comparison criteria that should be recorded.
- What decision must the assessment support, and by when?
- Which behavior, data, and dependencies are critical enough to verify directly?
- What access can be granted without increasing operational or security risk?
- Which unknowns must be resolved before selecting a disposition?
Apply the framework
Apply the framework to a real situation.
- Clarify the decision, criticality, users, operating calendar, and excluded scope.
- Observe tasks and inspect code, runtime, data, interfaces, jobs, and support records.
- Test high-impact assumptions with characterization or technical probes.
- Compare options against continuity, changeability, data, control, and cost conditions.
- Recommend the smallest next action that resolves material uncertainty.
Reader output
The output the reader should produce.
- Application scope, stakeholder, and decision brief
- Behavior, workflow, data, and dependency inventory
- Technology, support, security, and operability findings
- Option comparison and recommended evidence-gathering steps
- Risk, assumption, and unknowns register
Decision clarity
A clearer decision, not merely more information.
- A behavior and dependency baseline appropriate to the decision.
- A data, operations, control, and support risk view with evidence gaps.
- Feasible next-step options and conditions rather than a predetermined rewrite.
- A bounded proof plan for the highest-uncertainty assumptions.
Misapplication
When can the framework create false confidence?
- Scanning tools may create a precise-looking but incomplete assessment.
- Rare, privileged, or seasonal behavior may not appear during observation.
- Inspection can disturb an unsupported environment if access is not controlled.
- A modernization recommendation may ignore the organization's ability to absorb change.
Decision questions
Test the interpretation before applying the guide.
Is old technology alone a reason to rewrite?
Lifecycle and support matter, but the decision also depends on critical behavior, data, dependencies, change demand, controls, and viable alternatives.
What if source code is unavailable?
Behavior can still be observed through users, interfaces, data, logs, jobs, and controlled tests, though uncertainty and constraints must remain explicit.
How long should an assessment take?
Set the duration from the decision, criticality, access, evidence quality, and the cost of remaining uncertainty.