MODERNIZATION TOOLING, HONESTLY: WHAT SCANNERS, TRANSLATORS, AND ASSESSMENTS CAN ACTUALLY DO
A clear-eyed map of legacy-modernization tooling: portfolio scanners, dependency mappers, rule extractors, code translators, and debt scanners - what each is good for, where each lies to you, and how to combine them with judgment.
Modernization tooling does four jobs well - inventory (what exists), dependency mapping (what touches what), rule extraction (what the code decides), and assisted translation (drafting the mechanical majority of a port) - and two jobs badly: judging what matters, and recovering why. Buy tools for the four; keep architects for the two. Every disappointing modernization-tooling story we've audited traces to inverting that.
The four jobs tooling does well
Inventory: you cannot modernize what you haven't counted
Estate scanners enumerate programs, jobs, screens, schedulas, and their sizes/ages/change-frequencies. Sounds trivial; isn't. Most enterprises are wrong about their own estate by double-digit percentages - orphan jobs still running, 'retired' programs still called monthly. The inventory is the map every later decision stands on.
Dependency mapping: the blast-radius calculator
Static analysis builds the call/data graph: which programs read which files, which jobs feed which downstreams. This is what turns 'can we touch billing?' from a séance into a query. Limits: dynamic calls and out-of-band integrations (file drops, humans re-keying) need runtime observation and interviews to complete the picture.
Rule extraction: candidate meaning, wholesale
Extractors lift conditional logic into readable candidate rules ('IF region = 7 AND amount > 10000 THEN route approval-B'). Treat output as testimony, not truth: rules come with no why, and dead branches extract as confidently as live ones. The workflow that works: extract wholesale, verify with characterization tests, annotate intent with humans.
Assisted translation: the boring 70%
Modern translators (increasingly LLM-assisted) draft target-language ports of straightforward code acceptably. The discipline is the review gate: every translated unit passes characterization tests before merge, and the hard 30% - batch orchestration, error handling, the weird parts - is re-engineered by humans, not translated.
The two jobs tooling does badly
Prioritization: scanners score code metrics, but business impact lives outside the code - which modules block the roadmap, which risks the CFO actually carries. Debt registers must be ranked by business consequence, which is an interview-and-judgment product. And WHY-recovery: no scanner knows the regulatory settlement behind Section 7. Intent lives in people; capture it while they're employed (see our COBOL playbook's Phase 0).
Assembling the honest pipeline
- Scan: inventory + dependencies + debt indicators (days).
- Interview: intent capture with the humans who know (weeks, overlapping).
- Register: one ranked list - risk × business impact × effort, owned by an architect, argued with the business.
- Pin: characterization harness on the first slices.
- Execute: translate the mechanical, re-engineer the meaningful, reconcile everything.
This pipeline is productized in our Modernize toolkit (assessment, migration tooling, debt scanner) and miniaturized in this site's free diagnostic - but the shape holds whatever tools you run: instruments measure, humans decide.