Reading the analysis
The analysis is what the platform understood about your legacy system. It is not a rewrite plan and it is not a specification yet — it is the evidence everything after it is argued from, and it is worth reading before you accept any of it.
As-Is Architecture
The legacy system's structure as extracted from the code: its components, how they relate, and where the boundaries fall. This is generated, so read it as a reading of the code rather than as a statement of intent. Where it is wrong, it is usually wrong in an informative way — it reflects what the code actually says rather than what the original design intended.
The database
Three surfaces, from different angles:
- DB ER Diagram — the entities and their relationships.
- DB Table Catalog — every table found, with its columns.
- DB Objects — views, procedures and the rest of what lives in the schema.
These come from the code and the schema as found. A table the legacy application never touches can still appear here; a table built by a process outside the codebase may not.
Views
What the legacy application presents to its users, screen by screen. The View Catalog is the inventory; individual views carry the detail. These matter more than they look like they should: a to-be scenario about a screen is anchored to the view it describes, and the implementation agents are told which view they are reproducing.
Modules
The module is the unit of work. Discovery, decision and delivery all happen a module at a time, on one branch, and one agent per role does a whole module's work. This is the single most useful organising idea in the product: if you are wondering why features are grouped the way they are, or why an implementation touched more than you expected, the module is usually the answer.
External systems
What the legacy system talks to, and what will happen to each: kept, replaced, or mocked.
A system marked for mocking gets an explicit mock strategy that implementation agents respect, rather than each agent inventing its own. Renaming or merging an external system keeps every scenario reference in step, and deleting one warns you about the references first and cleans them up rather than leaving scenarios pointing at nothing.
The legacy code itself
The Legacy Code Viewer shows the source. You will mostly arrive here from a scenario: a scenario's related files open at the lines they were annotated with, so you land on the code the behaviour was extracted from rather than at the top of a file.
What is extracted, and what is inferred
Worth holding in mind as you read:
- The database catalogs, the view inventory and the file-level structure are extracted. They are what the code contains.
- The architecture, the module grouping and the scenarios are inferred. They are a model's reading of the code, and they are what you are being asked to review.
Requirements-based analysis, where your installation has it enabled, is deliberately kept out of the as-is Gherkin: a requirement is something you want, and the as-is records only what the legacy system does.
Re-running it
Analysis is re-runnable. The common reasons are a codebase that has moved on since it was uploaded, or an analysis that was clearly wrong about something structural. Re-running replaces the analysis, so review anything you have already decided before you do.