calls to the backend found
counted in codeSummary
This page follows each user-facing function through the code: screen → service → backend → database. Everything shown was found in the source code. The code map cannot show actual usage, estimate effort, or set a timeline. You can enter team days per code-size category in the Sequencing section.
System flow
functions; linked to interface calls
matchedbackend contracts matched
contract on fileDatabase and outside-system use per part
partial coveragelive use not measuredMigration workload detail
What each entry point and cohort costs to port: traced functions, data stores, files, gaps, and sharing. Use the Status column as the next action per row. Use the Sequencing section for port order and the evidence behind it. No timeline follows from these counts.
| Queue position | Part / candidate | Status | Entries | Gaps | Shared resources | Methods / repositories | Proven prerequisites |
|---|
Candidate subdivisions of the selected part
Use these cohorts to split the part into shippable chunks. A cohort shares its listed methods, data, and gaps with every entry that reaches them: those entries move together or stay compatible.
Migration sequencing constraints
A part listed as needing another was reached from the first part's entry points in code: port the need first, or port both together. Tiers run migration-first first; parts in one tier have no ordering evidence between them; parts in one port-together group move as a unit regardless of tier. "Port together" groups are same-area aliases or dependency cycles. Links are code reached through user flows, backend service calls, shared data stores, or direct code wiring. Strength counts traced paths (a single lead is one path: verify before relying on it). Unconstrained parts have no directional evidence and can move whenever their platform modules are available. Business areas group parts only when the team supplies a capability map; without one, every part is ungrouped. This is a permitted order, not a rollout plan: business priority, runtime use, and release constraints need team input.
Port together
Port in this order
No directional code constraint
Why this tier
Why: constraint evidence
| Part | Needs | Kind | Strength | Evidence paths / methods |
|---|
Platform first
Shared modules reached from many parts. They must stay available throughout; stabilizing them early unblocks the most dependents.
| Shared module | Dependent parts | Reached functions |
|---|
Per-part workload signals (not estimates)
Size, past-change, and coupling signals for calibrating effort against a team-measured reference migration. Counts are static: shared code appears in several parts, untraced work is missing, and no timeline follows from these numbers. Complexity bands group static code size only. They are not effort estimates; type your own days for each band and the table totals the plan. Click a column heading to sort.
| Part ↕ | Business area ↕ | Band ↕ | Tier ↕ | Entries ↕ | Functions ↕ | Files ↕ | Past changed lines ↕ | Entries with gaps ↕ | Needs ↕ | Needed by ↕ | Days ↕ |
|---|
Explore actual dependencies
Inferred part-to-part coupling from traced paths is listed under Sequencing; what follows explores individual code paths. The dependency explorer follows entry points through methods, SOAP services, and persistence. Start with a candidate in the review order above, then inspect its code paths and shared dependencies there. Test coverage not measured.
Risk indicators
Five separate relative scores per part, from 0 to 100. Complexity is an entry-and-reach size proxy, not an effort estimate: it counts entry points and reached graph members, but shared code can appear in several parts and untraced work is missing. Hover for the raw counts. Past changes indicate activity, not quality. The code analysis does not produce a delivery time or effort range. Any days shown in the Sequencing table are entered by the user.
| Part ↕ | Area ↕ | Code reach ↕ | Used by others ↕ | Depends on others ↕ | Contract reach ↕ | Past changes ↕ | Past edits ↕ |
|---|
Evidence and limitations
For a specific function, inspect its path in the dependency explorer or the downloadable traces. The pairwise matrix flags shared resources for investigation, but unknown means insufficient coverage, not safe parallel delivery.
How much is mapped
How solid the findings are (portal code)
What couldn't be traced (portal code)
Outside systems we depend on
Traced service operations without local implementations, plus Elasticsearch, Quartz, and LDAP SDK boundaries. Code evidence does not measure live use.
What this analysis cannot tell you
- A snapshot of the code, not live traffic.
- Test and helper code is excluded from these counts.
- No staffing or schedule. Day values are entered by you and are not written into the report files.
- “Likely” connections are leads, not proof.
- Past-change counts measure activity, not quality.
- One function can appear in several parts.
Untraced code references (portal code)
Code references the analysis couldn't connect, grouped biggest-first. Use it to judge how complete the picture is.
| Called function | Reason | References | Examples |
|---|
Functions in the selected part
| Function | Kind | Address | Interface link | Found in | Uses |
|---|
Raw data for analysts: Full graph JSONAll nodes CSVAll edges CSVOperations CSVEntry-point evidence CSVCandidate subdivisions CSVCode-based review order CSVBlock metrics CSVWave data CSVParallel matrix CSVUnresolved links CSVUnresolved calls by part CSVTraces JSONTraces CSVHot symbols CSV