How Consultancies Can Make Legacy Discovery Phases More Evidence-Based

A stronger discovery phase connects business questions to verifiable system evidence before scope, cost, and target architecture are fixed.

A discovery phase is expected to reduce uncertainty. Yet on a large legacy estate, discovery can easily become an exercise in collecting incomplete documents, interviewing a limited group of experts, and extrapolating from a small sample of code.

Those inputs are valuable, but they are not the system itself. The people who know the estate best may remember why a design decision was made, while existing documentation may explain intended behaviour. Neither source necessarily shows every dependency that a proposed change will touch today.

For a consultancy preparing a modernization program, that distinction matters. Early assumptions can shape the delivery model, the migration sequence, the target architecture, and the estimate presented to the client. If those assumptions are not tied back to code and system relationships, uncertainty is merely transferred into later phases.

A useful discovery phase does not pretend to remove uncertainty. It makes uncertainty visible, traceable, and easier to test.

Start with questions, not a predetermined destination

Modernization discovery is often framed around a target: replatform, refactor, replace, or retire. The more important first question is whether the current system is understood well enough to judge any of those options.

That requires questions such as:

• Which applications, programs, jobs, interfaces, files, screens, and databases participate in each critical business process?
• Where do business rules actually reside?
• Which shared components create dependencies across application boundaries?
• How does important data move through online and batch processing?
• Which parts of the estate appear unused, and what evidence would be needed before treating them as removable?
• Where does the team depend on expert interpretation because system evidence is incomplete?

These questions keep discovery focused on decisions. They also expose where interviews and documents need support from direct technical analysis.

Build an evidence model for every important conclusion

A discovery report is more useful when a reviewer can see how each major conclusion was reached. That does not mean attaching raw source listings to a presentation. It means maintaining a clear connection between a recommendation and the evidence behind it.

For each high-impact conclusion, a consultancy can record:

1. The decision the conclusion is intended to support.
2. The source evidence examined, including code, dependencies, data flows, interfaces, jobs, and relevant documentation.
3. The assumptions still being made.
4. The areas that require validation by client experts.
5. The consequence if the conclusion is wrong.

This simple discipline changes the quality of the conversation. A statement such as “this application is isolated” becomes a testable claim. The team can ask whether shared copybooks, called programs, JCL, database access, files, or external interfaces contradict it.

Analyse relationships across the whole execution context

Legacy systems rarely fit inside a single language or repository boundary. A business function may pass through COBOL or PL/I programs, Assembler routines, JCL, CICS transactions, DB2 tables, IMS structures, batch files, reports, screens, and interfaces to Java applications.

Text search is helpful for locating known terms. It is less reliable as the main basis for understanding these relationships. Names may be reused, values may move through intermediate fields, and execution paths may cross technical boundaries that are not obvious from one source file.

The discovery team therefore needs several complementary views:

• cross-reference analysis to locate definitions and uses
• dependency analysis to trace relationships between technical objects
• data-flow analysis to follow important values through the system
• impact analysis to explore the likely reach of a proposed change
• dead-code investigation to identify candidates for closer review, without assuming that apparent inactivity proves safe removal

Panorama is designed for this kind of code comprehension and software intelligence work in large legacy and enterprise codebases. It can help a consultancy inspect system evidence across supported technologies before recommendations are fixed. Expert review remains essential: tools make relationships visible, while experienced people interpret their business and delivery significance.

Use sampling deliberately

Time-boxed discovery usually requires sampling. The risk is not sampling itself, but allowing a convenient sample to stand in for the whole estate.

A better sample covers meaningful variation. That may include online and batch workloads, heavily changed and stable applications, shared and isolated components, different languages, different business domains, and systems with different documentation quality.

The team should state what the sample can and cannot support. If a detailed dependency analysis covers one application, it may reveal a recurring pattern worth testing elsewhere. It does not automatically prove that the same pattern applies across the estate.

Separate facts, interpretations, and recommendations

Discovery deliverables often blur three different things:

• **Facts:** relationships or behaviours supported by inspected evidence.
• **Interpretations:** what those facts may mean for risk, effort, or architecture.
• **Recommendations:** what the client and consultancy should do next.

Keeping them separate makes review more productive. Client experts can challenge an interpretation without disputing the underlying technical evidence. Decision-makers can compare recommendations while seeing which assumptions carry the most risk.

This separation is particularly important when the discovery phase informs a commercial estimate. An evidence-based estimate is not a promise that all uncertainty has disappeared. It is a clearer account of what was inspected, what remains unknown, and where contingency may be justified.

Turn discovery findings into validation work

The best discovery outputs are not static inventories. They define what needs to be validated before a program commits to irreversible choices.

Useful outputs can include:

• a map of critical application and data dependencies
• a list of assumptions ranked by delivery consequence
• business processes that need deeper technical tracing
• components that require expert review before migration sequencing
• apparent dead-code candidates requiring runtime or operational validation
• knowledge gaps that should be addressed before key experts become unavailable
• a prioritized plan for further analysis

This gives the next phase a concrete starting point. It also helps the client distinguish between work that is understood, work that is merely assumed, and work that remains genuinely unknown.

Evidence improves the quality of scope conversations

A consultancy earns trust in discovery by being precise about what it knows. Systematic code comprehension does not replace workshops, architecture judgement, or the knowledge of the people who operate the system. It gives those activities a stronger technical foundation.

For ITP Software, the central principle is straightforward: understand the system before changing it. Panorama helps teams examine code relationships, dependencies, and data movement so modernization decisions can be reviewed against the estate as it exists, not only as it is remembered or documented.

That makes the discovery phase more than a preliminary step. It becomes a defensible basis for deciding what to modernize, in what order, and with which uncertainties still open.