Portal migration analysis

What the portal is made of, how its parts connect, and where the migration risks are (generated from the source code).

Please note: no migration sequence has been approved. Directional links may suggest a review order; absent links do not establish that parts are independent.

Summary

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

User interface

calls to the backend found

counted in code
Backend entry points

functions; linked to interface calls

matched
Service contracts

backend contracts matched

contract on file
Data and outside systems

Database and outside-system use per part

partial coveragelive use not measured

Migration 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 positionPart / candidateStatusEntriesGapsShared resourcesMethods / repositoriesProven 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

PartNeedsKindStrengthEvidence paths / methods

Platform first

Shared modules reached from many parts. They must stay available throughout; stabilizing them early unblocks the most dependents.

Shared moduleDependent partsReached 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 functionReasonReferencesExamples

Functions in the selected part

FunctionKindAddressInterface linkFound inUses

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