Modernization Workflows

Each workflow below is a DAG over the modernization capabilities, executed with the machinery described in the rest of this site. They differ in their objective, not in their infrastructure.

Characterize before you transform

Legacy modernization has one powerful trick. Before changing poorly understood code:

That allows:

Understand by observing before transforming.

Agents are well suited to generating these characterization harnesses — it is exactly the kind of careful, tedious, high-volume work humans postpone. For old C and C++ medical-device software it can be enormously valuable, and it is why characterization sits near the root of the migration DAG: it turns every downstream node into something an agent can verify itself against. It is also the natural way to settle the hypotheses an agent forms while reading the code.

Feature migration between codebases

Suppose the goal is:

Transfer automatic vessel detection from ultrasound platform A to platform B.

A capable agent system decomposes that into:

The key step is the middle one: reconstruct the feature's semantics, not just its code. The reconstructed feature specification covers:

• observable behaviour, inputs and outputs, configuration
• algorithms and data structures
• hardware assumptions and timing constraints
• dependencies and failure behaviour
• safety implications and performance characteristics
• existing test evidence

Then differential testing makes "done" measurable:

This gives the agent a measurable objective rather than "make B behave like A." The comparison belongs in the work item's required_evidence, with its tolerance in constraints.

Vulnerability remediation

Automated, test-verified and behaviour-preserving. The goal is to eliminate CVE-X without changing externally observable behaviour:

This is the canonical case for verifier-driven development: the scanner, the build and the tests define success, not the agent. At portfolio scale — the same CVE across twenty repositories — it is also the canonical end-to-end flow.

Architecture recovery

Architecture recovery can itself be agentic. An agent can recursively discover:

Future agents then consume these artefacts instead of rediscovering everything. That is how the system gradually acquires organisational intelligence — provided the artefacts follow the same rules as any other learned knowledge: committed to the repository, reviewed, and re-derived when the code moves.

Two by-products are worth calling out:

• Recovered module boundaries are the first draft of your ownership domains. They are the natural input to domains.yml.
• The dependency graph is an honest modularity score. It predicts how many agents can work in parallel before they do — see Platform.