Managers
What static evidence exists before scope is approved, which rows are hidden, and which coverage gaps need human planning time?
Legacy modernization evidence map
Modernization planning starts with static evidence, not a safety claim.
This concept page maps legacy modernization questions to deterministic static repository evidence, coverage gaps, hidden surface families, and public-safe proof routes. It works from repository snapshots and checked-in artifacts, not live systems.
Public claim level: concept. No public conclusion without evidence. This page is a reviewer-question map for modernization planning, not the legacy evidence story and not the legacy validation plan.
Reader questions
Different reviewers need different evidence prompts.
Architects
What old project shapes, framework clues, service families, UI surfaces, and data metadata families need design review?
Engineers
Which evidence came from semantic analysis, structural patterns, syntax fallback, config or project metadata, or an explicit analysis gap?
Reviewers
Where are the rule IDs, evidence tiers, coverage labels, limitations, proof paths, and non-claims that bound each public statement?
Evidence map
Legacy concerns stay beside status, limitation, and proof path.
| Legacy concern | Reviewer question | Evidence shape | Public status | Limitation | Proof path |
|---|---|---|---|---|---|
| Old frameworks and toolchains | What target framework, project style, package, restore, generated-file, or toolset clues are visible? | Static project and repository metadata used as planning input. | concept |
Framework clues do not prove package compatibility, migration feasibility, or live deployment state. | Evidence model; capability boundaries. |
| Project load and build gaps | Did semantic project load succeed, or does the scan need reduced-coverage labeling? | Coverage labels and analysis-gap evidence for failed project load, missing build context, or partial analysis. | concept |
Failed build or project load is reduced coverage, never a clean repository result. | Limitations; legacy validation concept. |
| Syntax fallback | When semantic evidence is unavailable, which checked-in syntax or text evidence still helps review? | Syntax-only or textual evidence that keeps useful facts visible with weaker evidence tiers. | concept |
Syntax fallback cannot resolve compiler symbols or prove behavior outside the repository snapshot. | Evidence tiers; validation map. |
| Config and project metadata | Which checked-in configuration or project files can guide reviewer questions? | Static config and project-file presence, metadata shape, and coverage labels. | concept |
This row does not assert service binding detection, service-reference detection, endpoint extraction, or connection-value extraction. | Proof path index; output boundaries. |
| WCF and service references | Which service-reference family would need architecture and owner review? | Named hidden surface family only. | hidden pending validation |
No public support result, reachable service claim, deployed endpoint claim, or binding compatibility claim is made here. | Hidden legacy evidence ledger. |
| WCF metadata normalization | Which metadata-normalization questions would need public-safe proof before publication? | Named hidden surface family only. | hidden pending validation |
No metadata support, downloaded metadata proof, endpoint value, or compatibility conclusion is published. | Hidden legacy evidence ledger. |
| ASMX and SOAP services | Which older service-host family would require reviewer follow-up? | Named hidden, unledgered surface family. | hidden pending ledger entry |
Unledgered here means no public support claim, route claim, operation claim, or service address is shown. | Hidden legacy evidence ledger; follow-up ledger gap recorded. |
| .NET Remoting | Which remoting-family references would need review before any public wording changes? | Named hidden surface family only. | hidden pending validation |
No hosted service, activation path, exploitability, or production-usage result is claimed. | Hidden legacy evidence ledger. |
| WinForms navigation and events | Which desktop UI wiring family would need source-owner review? | Named hidden, unledgered surface family. | hidden pending ledger entry |
No event support claim, navigation claim, user-action claim, or runtime UI reachability claim is made. | Legacy validation concept; follow-up ledger gap recorded. |
| WebForms events, routes, and navigation | Which WebForms UI family questions belong in review before modernization scope is set? | Named hidden surface family; route and navigation aspects are unledgered here. | hidden pending validation and ledger entry |
No event execution, route reachability, navigation behavior, ViewState, or postback simulation claim is made. | Hidden legacy evidence ledger; validation concept. |
| Legacy data metadata | Which old data metadata families would require database and owner review? | Named hidden surface family only. | hidden pending validation |
No database existence, query execution, schema compatibility, permission, or production data result is claimed. | Hidden legacy evidence ledger. |
| Build environment diagnostics detection | Which environment-diagnostic family would explain why coverage is reduced? | Named hidden surface family only. | hidden pending validation |
This hidden row does not turn missing toolchains, restore failures, or generated-file gaps into install advice or clean results. | Hidden legacy evidence ledger; limitations. |
| Flow composition reporting | Which static path-composition questions would need proof before being repeated publicly? | Named hidden surface family only. | hidden pending validation |
No runtime flow tracing, full dependency result, release decision, or migration completeness claim is made. | Hidden legacy evidence ledger. |
The map is intentionally sparse. A hidden row can help a reviewer ask the right question without becoming public support language.
Coverage gaps
Evidence tier language keeps partial analysis useful.
Tier1SemanticCompiler-resolved static symbol evidence when project load and semantic analysis succeed.
Tier2StructuralKnown framework, project, or file-structure patterns that can guide review with limitations visible.
Tier3SyntaxOrTextualSyntax-only or text evidence used when stronger analysis is unavailable or reduced.
Tier4UnknownAnalysis gaps, unsupported formats, malformed metadata, or unable-to-prove states that block stronger conclusions.
Non-claims
The map is planning context, not modernization approval.
- No runtime behavior, production traffic, endpoint performance, outage cause, release safety, operational safety, production dependency understanding, exploitability, database existence, package compatibility, migration feasibility, migration completeness, AI impact analysis, LLM analysis, or complete product coverage proof is claimed.
- Static evidence does not replace runtime telemetry, source-owner review, architecture review, security review, database review, test results, build or restore validation, migration planning, release approval, code review, governance, or human judgment.
- Rows avoid impact wording unless a deterministic reducer result with public-safe rule IDs, evidence tiers, proof path, and limitations supports that exact statement.
Proof paths