Migration approach, complexity and effort baseline

1. Basis of the estimate

We are porting proven portal behaviour into the new platform, not rebuilding the product. Existing business rules, validation and automated tests are carried across. The remaining effort is concentrated in service contracts, data access, configuration, module boundaries and integration testing.

Delivered platform capabilities, including security, data access, messaging, scheduling, observability and shared client libraries, are treated as established enablers. They are not charged again as feature work.

2. How the work is divided

The portal is divided into business parts based on the outcome delivered to the user, rather than the physical repository layout. Each part has one accountable owner, defined acceptance criteria and independent test coverage.

The analysis identified 39 parts. Five pairs describe the same scope under different technical names, so they are combined into 34 planning groups. This ensures that coupled or duplicate scope is assessed and estimated once.

3. How complexity is calculated

Every planning group receives a scope score based on three observable measures:

• Entry points: user-facing operations and internal triggers such as scheduled jobs and message consumers.
• Traced functions: distinct production business functions reached from those entry points.
• Files: distinct production files contributing to the reached implementation.

Each distinct entry point, function and file contributes one unit. The scope score is the sum of these three measures. It measures the amount of behaviour involved, not difficulty or duration. One scope unit is not one day.

Each of the 34 planning groups has one scope score. The categories are defined by percentile, creating four equal-sized bands across the current portal:

• S: the lowest quartile, up to the 25th percentile.
• M: the second quartile, between the 25th and 50th percentiles.
• L: the third quartile, between the 50th and 75th percentiles.
• XL: the highest quartile, above the 75th percentile.

This is a relative ranking of the current portal, not a fixed industry standard. The percentile boundaries are recalculated on each analysis so the categories remain representative of the portal being assessed. The current distribution is 8 S, 9 M, 9 L and 8 XL groups.

Current examples show how the classification works:

• Settings: 2 entry points + 23 functions + 7 files = 32 units, classified as S.
• Reference Data: 38 entry points + 71 functions + 32 files = 141 units, classified as M.
• Agreements: 21 entry points + 264 functions + 51 files = 336 units, classified as L.
• Projects: 74 entry points + 1,021 functions + 191 files = 1,286 units, classified as XL.

4. How scope becomes an effort estimate

The size band provides an evidence-based grouping, while duration remains a delivery assumption. The delivery team assigns a number of person-days to each S, M, L and XL category using completed migrations as the reference point.

The total is the sum of the assigned days for all planning groups in each category. Coupled parts are counted once, and the calculation is visible in the reporting tool so every assumption can be reviewed or changed.

This separation keeps the commercial estimate transparent: the client can see the measured scope behind each part, the day rate applied to its category and the effect of any change on the total. Normal unit, integration and contract tests for each part are included.

5. Risk assessment

Size is reviewed separately from risk. The estimating team considers cross-part dependencies, external contracts, workflow state changes, data and permission complexity, and the depth of existing test coverage.

The main risk areas are:

• Projects: the largest surface, many connected workflows and several external dependencies. Errors can affect multiple downstream areas.
• Model as a Service and Enrichment: long external lifecycles and multiple integrations, increasing coordination and recovery risk.
• Identity parts: users, roles, groups and authentication. Permission gaps have a broad impact and are costly to correct late.
• Rules-heavy parts: agreements, data views, risk designs and dataset criteria. Code does not reveal every business dependency, so these require early client confirmation.

6. Why four delivery modules

The code analysis places the constrained parts into four dependency layers. These modules prevent teams from waiting for capabilities that are not yet available, while allowing parts within the same module to proceed in parallel.

1. Data Views, Model Images and Job Scheduling: leaf capabilities with limited downstream dependencies.
2. Projects, Model as a Service, Enrichment, Tools, Crisis Response and Email: core capabilities with the largest data and external-system impact.
3. Users, Roles and Groups: shared identity and access capabilities required by later work.
4. Authentication, User Details, Business Audit, Model and Risk Analysis: cross-cutting services completed once shared foundations are stable.

Separately movable parts: Agreements, Reference Data, Notifications, Settings, Dataset Criteria and Risk Designs. They can run in parallel once their shared platform modules and agreed business dependencies are available.