- 10When are specifications not enough?
- 11Where is the state of the work kept?
- 12Who prepares a change before coding starts?
- 13What does impact analysis tell you, and when does it run?
- 14How do coding agents use the graph?
- 15How is each change checked, and how does the graph stay current?
- 16Who decides which work agents do?
- 17How do managers see what people and agents are doing?
- 18What happens across many products?
- 19What about existing systems and technical debt?
- 20What changes for the team?
- 21What results have teams seen?
Home / Follow the story / Act 4: Legacy modernization, with ASIMOV
Loading the video
Transcript
22. The modernization tax
In a legacy modernization, a team replaces an old technology stack with a modern one, and keeps the behavior the business has built up over years. The people who could once explain the legacy system are often retiring, scarce or already gone. The legacy code is the only authoritative record of what the system actually does. The cost of working from that record by hand is the Modernization Translation Tax, and the tax has four components. The reverse-engineering tax is the work of finding out, from the legacy code, what the system does, which needs senior engineers. The lost-context tax covers business decisions the code does not show, such as deliberate edge cases and old workarounds. The validation-vacuum tax arises because nothing can test the old behavior automatically, so every migrated module needs a hand-built check that it behaves as before. The knowledge-disappearance tax arrives after the project, when the people who built up the understanding leave with the engagement. The first three components make each other worse. Without an executable contract that proves the new system behaves like the old one, nobody can show the migration is complete. A modernization that cannot be proven complete stalls before it can deploy.
On the site: The Modernization Version of the Problem · The Four Components · Why the Tax Compounds
23. Graphs of the old and new systems
The methodology replaces this manual work with three structured records, each fixed for the length of the project. The Source-state ontology is a graph of the old system, built from the legacy code by agents: its files, classes, functions, statements and APIs. The Source-state ontology keeps the actual code statements, as evidence of the behavior the new system must reproduce. The Target-state ontology is a graph of the new system, built from the target blueprint: its architecture, runtime, standards and design system. The specification connects the two graphs, and produces a requirements document, test scenarios, end-to-end test scripts and a chatbot that answers questions about the code. The Product Owner and Architect mark every module of the old system, in the specification, with one of four decisions. Retain keeps the module's behavior while its structure changes. Modify changes the behavior in defined ways that the Product Owner records. Replace hands the function to a different solution, such as a modern library. Retire removes the function, and the retired items stay documented. A module without a decision cannot be migrated.
On the site: The Three Modernization Ontologies · The Source-State Ontology in Detail · The Target-State Ontology in Detail
24. The parity contract and the four gates
Together, the two graphs and the marked-up specification form the parity contract: the agreed definition of how the new system must behave, which the agents must follow. Neither the recorded legacy behavior nor the target architecture can change during the project. Migration agents write the new code one module at a time, from the specification and the Target-state ontology. Every piece of migrated code then passes through four validation gates, each run by its own agent. The architecture gate checks conformance to the target blueprint's architecture. The design gate checks the design system and UI guidelines. The standards gate checks security rules and coding standards. The functional gate checks that the new code behaves like the legacy code recorded in the Source-state ontology. Code that fails any gate goes back with the gate's evidence attached, until all four gates pass. Nine named agents cover five stages: Discover, Document, Migrate, Validate and Maintain. People check the work at two points: the decisions in the specification before migration, and a modernization expert's review of the code that has passed the gates. The five stages run on a platform called ASIMOV.
On the site: The Parity Contract · Named Agents · Validation Stage Agents
25. Five engagement modes and five delivery stages
A modernization client enters through one of five engagement modes, each sized to the work the client is ready to commit to. The modes differ in how much of the work the client takes on. Documentation Only produces documentation and test scenarios from the legacy code, with no migration. Discovery and Documentation adds an inventory of the applications, maps of their dependencies, the business rules, and review material for subject-matter experts. Migration Readiness adds a scope for each module, its place in the new system, the order of migration, and the marked-up specification. Full Modernization runs the whole pipeline, over quarters to years. Maintain, Operate and Convergence keeps the knowledge graph up to date on the modern system. Each mode addresses a defined part of the modernization tax, and a client may stop at any mode. Full Modernization runs in five stages: discovery and analysis, building the graphs, migrating one first module, migrating the rest, and user acceptance testing with deployment. While the first module is migrated, subject-matter experts review the output and tune the agents to the project.
On the site: Why Engagement Modes · The Five Engagement Modes · MTT Components Addressed by Each Mode
26. Results, and the handover
More than fifteen million lines of legacy code have been modernized with ASIMOV, across more than ten programs. On a one-million-line standalone codebase, the indicative figures are up to four times faster than manual modernization, and up to seventy percent less migration time. An inventory and warehouse platform moved 2.1 million lines from Java 8 to Java 21 in about three and a half months. A European education-technology provider moved three million lines of Delphi to cloud-native .NET 8, with about sixty percent less effort than manual. Actual outcomes vary by engagement scope, target stack and the modules selected. When a modernization completes and the client wants ongoing governance of the new system, a four-layer graph is built for it. The code layer is then extracted from the new code by Breeze.AI's agents, so the graph matches the modernized system from the start. The Retain and Modify decisions in the specification become the starting point for the functional layer. The target blueprint becomes the starting point for the architecture and design layers. The same four custodians continue, and the work moves from project stages to regular sprints.
On the site: Numbers from Real Engagements · Aggregate Track Record · Version and Platform Upgrade: Inventory and Warehouse
Choose a path
The full video in six parts and an appendix, one part at a time.