★ The decision guide · Angular 8 → 17+
Your Angular 8 app still runs, so the topic can wait — that's the reasoning that makes the migration more expensive every quarter. Legacy versions no longer receive security fixes, ecosystem libraries die one by one, and developers willing to work on them get scarcer. The real question isn't 'should we migrate' but 'migrate, rewrite, or deliberately do nothing' — three legitimate answers, provided you pick with the right criteria. Here they are, drawn from an 8 → 17 migration I ran in production with zero downtime.
+cost
every quarter you wait — security, hiring, libraries
3
real options: migrate, rewrite, do nothing
9
major versions crossed in prod, 8 through 17
0
minutes of downtime during that migration
It's invisible in the budget, but it's there: unpatched vulnerabilities on an end-of-life framework, abandoned libraries you end up forking to keep alive, and hiring that gets harder — good developers avoid legacy. Doing nothing is a valid choice on one condition: the application has a known end date. Otherwise it's just compounding debt.
Rewriting seduces because it's a clean slate — which is exactly the problem: for twelve months, the team rebuilds what already exists instead of shipping. A rewrite only defends itself if the product is changing radically at the same time, or if the codebase is so untested that every change breaks something else. If the app does its job, you migrate it — you don't raze it.
The cause isn't technical, it's organizational: no product owner tolerates six months without a new feature. The migration branch falls behind production, conflicts pile up, and the project dies half-merged. The antidote: one major version at a time, every step releasable, urgent features still shipping in parallel. That's how I crossed nine majors without an interruption.
Four signals predict cost better than codebase size: test coverage (your safety net at every version bump), the number of abandoned third-party libraries (each one is a decision), the age of your RxJS patterns, and any custom build setup. My audit prices those four and produces a version-by-version plan — including when the conclusion is 'don't do it now'.
8→17
The migration happened while the application lived: regular releases, zero interruption, and users noticed nothing — which was the point. The detailed traps (dead libraries, RxJS, stubborn schematics) are in the note published on this site.
CI
Tests, lint and build on every version bump in the pipeline: when something breaks, you know within the hour, on the branch — not three weeks later through a user.
After
A modern Angular codebase — standalone components, signals — a team that understands every decision because they migrated alongside me, and a CI that guards the next version bumps. The mission ends; the maintainability doesn't.
Join the waitlist: people on it hear first when a freelance slot opens up. Leave your email below, or write to me directly at alielmufti25@gmail.com.
Join the waitlistHonestly: it depends on four signals — test coverage, abandoned libraries, RxJS patterns, custom build setup — far more than on codebase size. That's what the initial audit, a few days, is there to price: a version-by-version plan with per-step estimates, before committing to anything.
Version by version, in nearly every case: Angular ships schematics between majors and the product stays shippable from start to finish. A rewrite only defends itself if the product is changing radically at the same time, or if the codebase is untestable. If that's your case, the audit will say so — rather than sell you months of migration.
Yes — that's the whole point, and it's how I ran mine: every step releasable, CI validating each version bump, urgent features shipping in parallel. Your users never notice a thing.
Defensible — if the application has a known end date: you secure the perimeter and let it live. Otherwise, at least price what standing still costs per year in security, hiring and library maintenance: that exercise usually makes the decision, not me.