Implementation sequence
Record the baseline
Preserve unrelated working-tree changes. Inventory external and inline templates, tracking functions, shared template references, and direct directive imports or queries. Record existing main and white-label build failures before migration.
Run Angular's official schematic
Preview and apply the control flow migration using the repository's installed Angular CLI. Review migration diagnostics and the changed-file list. Keep routing, styling, module structure, and business logic outside this change.
Review and repair the generated changes
Resolve remaining directives and template errors. Preserve aliases, loop context variables, template reuse, and tracking intent. Remove obsolete imports only after checking their uses; retain CommonModule where other directives or pipes need it.
Validate builds and user behavior
Build the main and generated white-label projects with the required 10 GB memory setting. Use manual behavior checks for the flows below and verify representative SSR output and hydration where enabled. Karma is configured, but there are currently no .spec.ts or .test.ts files under src; do not assume existing automated test coverage.
Close with evidence
Repeat the legacy-syntax scan, classify remaining matches, and review the final diff. Record build results, tested flows, migration warnings, and unresolved failures.
Where to start reviewing
Prioritize these groups when reviewing the generated changes:
- 135 conditional usages with
elseorthen. - 85 conditional
asaliases. - 84 loops with
trackBy. - 238 loops mentioning
index,first, orlast. - 15 files using
ngSwitch.
These are current text-scan counts and may include comments. Groups overlap and mix occurrences with files, so they are review priorities, not a count of unique locations. Refresh the inventory before migration and still review the overall diff.
Where manual review matters
| Area | Review requirement |
|---|---|
| Loop tracking | Preserve existing trackBy semantics. Avoid switching changing lists to index tracking without checking the consequences. Verify insertion, removal, reorder, and item replacement. |
| View reuse | @for can retain a view when a tracked property changes on the same object, as documented by Angular. Separately, changing tracking from object identity to an ID can reuse views for replacement objects with that ID. Preserve tracking intent and check state where remounting previously mattered. |
| Conditional templates | Check aliases, nested branches, and shared ng-template references. Preserve templates still used by outlets, queries, or other consumers. |
| Switches and wrappers | Verify cases, defaults, and content outside cases. Check wrappers whose removal could affect styling or content projection. |
| Imports and queries | Review TypeScript references to the old directives. Compilation may not expose a query that now returns no directive. |
Validation priorities
Start with shared components, then focus on heavily changed templates and behavior-sensitive flows.
| Flow | States to verify |
|---|---|
| Profile and post detail | Loading, empty and populated content, access restrictions, and conditional actions. |
| Messages and post cards | New items, reorder, selection, retained input state, and media state. |
| Shared tables and forms | Loading and empty rows, sorting, selection, validation errors, and conditional fields. |
| Create plan and wallet modal | Branch changes, validation, case/default content, and opening or closing. |
| Marketing and white-label pages | Tenant content and theme, server-rendered output, client navigation, and hydration where enabled. |
Use builds and manual behavior checks as the validation baseline. Add focused regression tests where the migration exposes behavior worth protecting. Use the existing running application; do not start a dev server. Record unavailable tenant configurations or authenticated flows as validation gaps.
Completion checks
- No active legacy control flow directives remain, including inline templates. Classify any remaining comments or examples.
- Main and generated white-label builds pass, with pre-existing failures and unavailable configurations reported separately.
- Selected behavior checks pass for conditionals, switch branches, list updates, and retained state.
- SSR and hydration checks pass for the selected routes where applicable.
- The final diff contains only the migration and necessary fixes, with validation evidence recorded.