Chronicle: Upgrading Angular 15 → 20 Under Active Development (Signals, Nx, PrimeNG) Without Freezing Features

Context from enterprise programs

Chronicle’s roadmap couldn’t stall. The app ran revenue‑critical dashboards for a telecom‑like analytics program. We needed Angular 20 for the Vite builder, Signals interop, and SSR options down the line—without slowing the team shipping new widgets every week.

• Multi‑tenant analytics app with 1K+ daily users

• PrimeNG + custom components; Nx libs for shared domain models

• Feature cadence: weekly releases tied to Q1/Q2 ad campaigns

Risks we had to control

I’ve been here before—airport kiosks, telematics dashboards, and employee tracking systems. The pattern is consistent: upgrades fail when you treat them as a single cliff jump. We turned it into a sequence of controlled, measured steps.

• Angular 15→20 spans multiple TypeScript and RxJS bumps

• PrimeNG breaking changes and style token updates

• Strict template/TS checks surfacing hidden regressions

The usual blockers

Upgrades often become a morale sink. Developers stop features, pile into a mega‑branch, and spend weeks diff‑mining. Business leaders see zero value until the last day—if it lands at all.

• Freeze attempts trigger hidden dependencies and morale dips

• Monolithic PRs are unreviewable and risky

• Uninstrumented UX regressions escape until production

Our counter‑pattern

We made the upgrade a background process that never blocked the mainline. Releases kept flowing. When a risky UI migrated, we flagged it and ran AB comparisons to prove no user‑perceived regressions.

• Parallel branch with weekly rebases and small PRs

• Feature flags for risky surfaces; runtime toggles via Firebase Remote Config

• CI gates: unit/e2e + Lighthouse/Core Web Vitals on every PR

1) Dependency & risk map

We enumerated breaks, then scheduled each step with a pass/fail gate. Nothing moved forward unless tests and UX checks were green.

• Angular 15→16→17→18→19→20

• TypeScript 4.8→5.x, RxJS 7.x, PrimeNG 15→17

• Target modern browsers to unlock smaller bundles

2) Incremental ng update plan

We executed the official path with checkpoints and restore points.

Command log

# lockfile hygiene
rm -f package-lock.json && rm -rf node_modules && npm i

# stepwise updates with checkpoints
npx ng update @angular/core@16 @angular/cli@16 --force
npx ng update @angular/core@17 @angular/cli@17 --force
npx ng update @angular/core@18 @angular/cli@18 --force
npx ng update @angular/core@19 @angular/cli@19 --force
npx ng update @angular/core@20 @angular/cli@20 --force

# framework-adjacent
npx ng update rxjs --from 7.5 --to 7.8 --force
npm i -D @angular-devkit/build-angular

3) Nx to contain blast radius

Nx let us upgrade leaf libraries first, run affected tests, and avoid breaking the world. We merged daily, kept main green, and reduced rework.

• affected:* targets to keep PRs small

• project graph to isolate shared libs and app shells

4) Feature flags for risky UIs

We exposed flags via runtime config. For teams already on Firebase, Remote Config works cleanly with a lightweight init and Signals.

Runtime flags code

// app.config.ts
import { APP_INITIALIZER, inject, provideAppInitializer } from '@angular/core';
import { signal, computed } from '@angular/core';
import { initializeApp } from 'firebase/app';
import { getRemoteConfig, fetchAndActivate, getValue } from 'firebase/remote-config';

export const flags = (() => {
  const _values = signal<Record<string, boolean>>({});
  return {
    get: (key: string) => computed(() => !!_values()[key]),
    setAll: (v: Record<string, boolean>) => _values.set(v)
  };
})();

export function initFlags() {
  const app = initializeApp({ /* env vars */ });
  const rc = getRemoteConfig(app);
  rc.settings.minimumFetchIntervalMillis = 60_000;
  return () => fetchAndActivate(rc).then(() => {
    flags.setAll({
      newSignalsDashboard: getValue(rc, 'newSignalsDashboard').asBoolean(),
      modernTable: getValue(rc, 'modernTable').asBoolean()
    });
  });
}

export const appInits = [
  { provide: APP_INITIALIZER, useFactory: () => initFlags(), multi: true }
];

5) Adopt Signals where it pays

We didn’t rewrite the world. We targeted hotspots—like a PrimeNG data table with frequent filters/sorts. Signals reduced render count and stabilized scrolling.

• High‑churn widgets switched to Signals/SignalStore

• Kept RxJS for streams; used interop for view state

Signals refactor snippet

// before: component held several Subjects + async pipes
// after: view state via Signals, stream interop for server events
import { signal, computed } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';
import { WebSocketService } from './ws.service';

export class DashboardComponent {
  private ws$ = this.ws.stream<Metric>("/metrics");
  data = toSignal(this.ws$ , { initialValue: [] as Metric[] });

  filter = signal('all');
  page = signal(1);
  pageSize = signal(25);

  visible = computed(() =>
    this.data().filter(d => this.filter()==='all' || d.type===this.filter())
  );

  paged = computed(() => {
    const start = (this.page()-1) * this.pageSize();
    return this.visible().slice(start, start + this.pageSize());
  });

  constructor(private ws: WebSocketService) {}
}

6) PrimeNG changes without churn

PrimeNG upgrades were staged behind flags and visual diff checks to avoid janky regressions.

• Tokenized theming; removed deprecated APIs

• Kept custom cells behind flags until QA signed off

7) Tests and UX gates

We fail the PR if Core Web Vitals regress beyond tolerance. It keeps us honest and gives PMs confidence.

• Cypress smoke flows on core journeys

• Lighthouse CI budgets: INP, LCP, CLS thresholds

Affected builds + Vitals gates

Fast feedback beats heroics. We used preview channels and automated vitals to keep scope tight.

• GitHub Actions matrix builds with Node 18/20

• affected:build/test/lint to speed iteration

• Lighthouse CI on preview URLs

Actions snippet

name: ci
on: [pull_request]
jobs:
  build-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [18, 20]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: ${{ matrix.node }} }
      - run: npm ci
      - run: npx nx affected -t lint,test,build --parallel=3
  lighthouse:
    needs: build-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx lhci autorun --upload.target=temporary-public-storage

Numbers stakeholders care about

These are the same categories I report on airline kiosks and insurance telematics dashboards—ship velocity, stability, and UX performance.

• Release cadence maintained: weekly throughout 6‑week upgrade window

• Critical regressions: 0 (no SEV‑1 incidents)

• Build time: 9m10s → 5m50s (‑36%) via Vite‑based builder

• JS bundle: ‑11.4% main, ‑18% dashboard chunk after modern targeting

• INP (p95 dashboard): 280ms → 210ms (‑25%)

• Unit tests: +142 new tests, 92.6% coverage on affected libs

Signs you need help now

If this sounds familiar, you don’t need a rewrite—you need a plan. I specialize in upgrades that keep shipping: Angular 12→20, AngularJS migrations, and chaotic codebase stabilization without derailing roadmaps.

• Feature freeze proposals pop up every planning session

• CI is red more than green; flaky e2e mask real issues

• Upgrades keep slipping quarter to quarter

Engagement pattern

I can lead, pair, or coach—remote, US/EU time‑zone overlap. See how I stabilize vibe‑coded apps at gitPlumbers and how I design components at NG Wave.

• Discovery and assessment in 3–5 days

• Upgrade plan with checkpoints, risk matrix, and CI gates

• Hands‑on delivery with your team, plus hiring/training support

Step‑by‑step playbook

This is a repeatable system I’ve applied across aviation, telecom, media, and insurance. It’s boring in the best way: predictable and defensible.

• Inventory and risk map (framework, TS, RxJS, UI libs)

• Set up Nx or project graphing to isolate blast radius

• Automate stepwise ng update with restore points

• Introduce feature flags + preview channels for risky flows

• Add UX gates (Lighthouse/Core Web Vitals) and smoke tests

• Adopt Signals selectively for high‑churn views

• Run ringed rollouts with instant rollback options

What to instrument next

Upgrades unlock options—SSR, Signals, modern builds. Instrument them so you can quantify impact in the next steering review.

• Server timing headers to spot SSR opportunities

• GA4/BigQuery export to track post‑upgrade UX trends

• Error sampling and typed logs for faster triage

Quick answers