A look back, written in 2026. Angular 2 arrived in September 2016 as a different framework wearing the same name, and a lot of teams spent the following year rewriting software that had been working fine.
What happened
Angular 1 had been the safe corporate choice: batteries included, blessed by Google, everywhere in enterprise. Angular 2 shared the name and almost nothing else — new language, new component model, new idea of how data moved. There was no upgrade path worth the phrase.
So every team on Angular 1 faced a three-way choice: stay and slowly lose support, rewrite into Angular 2, or rewrite into something else entirely. All three were expensive.
The part that was nobody's fault
The new design was better. The old digest cycle was genuinely hard to reason about at scale, and the changes addressed real problems. This was not vandalism.
But the cost did not land on the people making the decision. It landed on a team with a roadmap, a client with a budget, and a product manager explaining a quarter with no visible progress.
When you are asked to approve a rewrite, the question is not “is the new thing better”. It is “better by enough to pay for a year of not shipping anything a customer will notice”. That bar is higher than most of us admit.
What I ask now, before any migration
What breaks if we do nothing for twelve months? Security patches, browser changes, a dependency that has gone unmaintained — those are real forcing functions. “It feels dated” is not.
Can it be done a piece at a time, with both versions running? If yes, the risk drops enormously. If the only path is a big bang, assume it takes twice the estimate and ask whether the business can absorb that.
Who carries the knowledge? A rewrite quietly discards years of small fixes that encode things nobody wrote down — the odd date format a client needs, the rule about which customers skip a step. Those bugs come back one by one.
The honest summary
Frameworks are a dependency on other people's decisions. You can reduce that exposure — keep business rules out of framework-specific code, prefer boring libraries, write down why something unusual exists — but you cannot remove it.
A decade on, the teams I see in the best shape are not the ones on the newest stack. They are the ones who can explain what their software does without opening it.
