Modern Angular
A 30-Day Modernization Plan for Mature Angular Apps
When 'modernize Angular' is too vague, force it into a calendar: audit first, small changes second, risky ideas in branches, decisions in writing. With Angular shipping a major every six months and six majors landing between v16 and v22, a written sequence is what keeps the work from turning into a campaign.
Days 1-3: audit before opinion
Run ng version, record Angular, CLI, TypeScript, Node, RxJS, Material/CDK, builders, test runner, and critical third-party dependencies. Run production build and tests. List warnings before fixing them. The official update guide is the right second tab to keep open, since it customizes by source version, target version, complexity, and dependencies like ngUpgrade or Material.
Search for Zone.js assumptions, manual subscriptions, timers, NgModules, large SharedModules, reactive forms, NgRx boundaries, and DOM-heavy libraries. The output is a short baseline document. If the first PR already changes behavior, the audit came too late.
# Angular modernization baseline
Angular / CLI:
Node / TypeScript / RxJS:
Build command:
Test command:
Known blockers:
First low-risk pilot:
Explicitly out of scope:Days 4-13: low-risk alignment
Start by aligning new code with the Angular patterns the team wants to repeat. Use standalone for isolated new components, modern control flow in templates you already touch, and Signals for local state where they remove boilerplate.
The official standalone migration docs are explicit about the safety net: 'Existing applications can optionally and incrementally adopt the new standalone style without any breaking changes.' That posture is the whole point of weeks 1-2. Schematics like ng generate @angular/core:standalone and ng generate @angular/core:control-flow cover the mechanical work; review focus stays on the patterns the team will repeat.
Do not convert a whole application to defend a thesis. The goal is a repeatable pattern the team can review. If the second PR is hard to explain, the pattern is not ready.
Days 14-23: controlled spikes
| Spike | Question | Evidence |
|---|---|---|
| Zoneless | Which flows fail when change detection is explicit? | Smoke tests for timers, forms, subscriptions, overlays, charts. |
| Vitest | Can a slice of the suite run faster without breaking tooling? | CI run for migrated specs and known mock/fake timer differences. |
| SSR/hydration | Do public routes need server rendering? | Baseline web vitals, DOM audit, hydration test. |
| Signal Forms | Is there a low-risk screen where the experiment teaches the team? | Isolated branch with current docs, no critical production dependency. |
Weekly outputs
The plan is only useful if every week leaves something the team can review. I would not measure it by how many APIs were touched; I would measure it by whether the next reviewer can make a safer decision.
| Week | Output | Review question |
|---|---|---|
| Week 1 | Technical baseline | Do we know versions, blockers, risky patterns, and commands? |
| Week 2 | Pilot PR | Did one low-risk pattern improve ownership without broad churn? |
| Week 3 | Spike reports | Do failures, timings, and rollback paths come from the real app? |
| Week 4 | ADRs and backlog | Can the team tell what becomes default, deferred, or out of scope? |
Days 24-30: decide and document
The last week is not for adding more experiments. It is for writing decisions: what becomes the default for new code, what gets migrated when touched, what needs more evidence, and what is explicitly not happening yet.
The output should be boring and explicit: control flow approved for touched templates, zoneless deferred after overlay failures, Signal Forms blocked from critical forms while the API is experimental, Vitest allowed only in a pilot package until CI data is better.
A short ADR is enough. Include context, decision, scope, out of scope, risks, and validation commands. This matters because modernization gets expensive when every reviewer has to rediscover the same decision.
# ADR: use Signals for local state in new components
Status: proposed
Context: existing app, mixed local state patterns, no Signals usage yet
Decision: adopt local Signals for new and touched components; keep RxJS for async streams
Scope: new code and touched low-risk features
Out of scope: replacing NgRx, services, or async streams
Risks: effect misuse, mixed patterns, accidental rewrites
Validation: tests, smoke flow, code review checklistReusable artifact
30-day sequence
- Days 1-3: audit versions, tests, CI, dependencies, and risky patterns.
- Days 4-13: ship one low-risk pilot PR that reviewers can repeat.
- Days 14-23: run isolated spikes for zoneless, Vitest, SSR, and experimental APIs.
- Days 24-30: write ADRs, backlog items, and explicit non-goals.
Sources checked
- https://angular.dev/reference/releases
- https://angular.dev/update-guide
- https://angular.dev/reference/migrations
- https://angular.dev/reference/migrations/standalone
- https://angular.dev/reference/migrations/control-flow
- https://angular.dev/reference/migrations/inject-function
- https://angular.dev/reference/migrations/signal-inputs
- https://angular.dev/guide/components
- https://angular.dev/guide/signals
- https://angular.dev/guide/templates/control-flow
- https://angular.dev/guide/zoneless
- https://angular.dev/guide/testing/migrating-to-vitest
- https://angular.dev/guide/forms/signals/overview
Modern Angular Playbook
This article is one play.
The Modern Angular Playbook collects the diagnostic, the adoption matrix, eleven plays, and the 30-day plan. Free, in English and Portuguese.
You get both PDFs by email, through the Dojo IA list.
André Ramosavailable for remote roles, UTC−3Get in touch →