Angular modernization in tested stages

1. A baseline you can trust.

   Identify the critical workflows, record the current behaviour and address tests that make regressions difficult to diagnose. Agree on the checks required for each migration stage.

2. TypeScript strictness and lint boundaries.

   Strict mode and a rule set that says which part of the code may import which. These checks catch some mistakes earlier; runtime validation and behaviour tests remain necessary.

3. Framework upgrades, one major version at a time.

   Each with the official schematics, its own commit and a green gate.

4. Standalone components and the new control flow.

   Mechanical where the schematics apply, by hand where a module hid a real dependency.

5. Signals for state and inputs.

   Use signals for synchronous state and computed values, and signal inputs where they fit. The output() API emits events; it is not a signal. Keep RxJS for asynchronous streams where it remains useful.

6. Check change notifications before going zoneless.

   Check template signals, event handlers, markForCheck() and other supported notification paths, including third-party components. OnPush is recommended, not a prerequisite for zoneless compatibility. Test rendered effects and late asynchronous updates; an OnPush conversion alone does not prove the migration works.

7. Nx workspace, if several applications share code.

   Libraries with one job each, affected-only builds and tests, boundaries enforced in CI.

GeoAtlas runs on Angular 22.1 without Zone.js, with forms built on Signal Forms; the modernization checklist article walks through the pitfalls of each step.

• Regression tests for changed behaviour, with targeted mutation checks where useful: deliberately break the implementation, see the test fail, then restore it.
• Important workflows and intended differences recorded per screen.
• Incremental merges to the main branch; no long-lived migration branch.
• A decisions register for every rule the team adopts, so the modernization survives staff changes.

The target is a code base your team can change with confidence: clear boundaries, reusable behaviour and a documented upgrade path. We choose practical measures for your bottleneck, such as build time or the effort needed to change a shared interaction. The plan and decisions stay with your team.

A modernization is cut into stages: a baseline, one migration step, one area of the application. Each stage has a defined scope, expected result and a tested release at the end. Timeframes depend on the size of the code base; we agree on them per stage, not for the whole journey at once.