You modernise a frontend when delivery speed predictably collapses: slow changes, side effects, blocked hiring. You rewrite only if the foundation is unrecoverable or the business domain has changed — and never all at once.
The false question
“Should we rewrite everything?” is almost always the wrong question. The right one is: what measurable gain are we expecting, and what risk are we accepting?
The signals of a modernisation to undertake
- Business-requested changes take weeks instead of days.
- Every addition creates an unexpected side effect elsewhere.
- New hires need months to become productive.
- The bundle grows faster than the features.
- The stack blocks hiring (dead framework, EOL versions).
If three of these signals are present, the debt is no longer a cost: it is predictably destroying speed.
When a rewrite is still justified
Rarely, but sometimes:
- The technology foundation is unrecoverable (no security support left).
- The business domain has changed so much that the data model lies about actual activity.
- The cost of progressive migration exceeds a well-scoped rebuild — computed honestly, operations included.
The method that avoids both traps
- Measure first: feature lead time, incidents, test coverage, bundle size.
- Isolate zones: debt is rarely homogeneous. Stable zones stay untouched; hot zones are modernised first.
- Strangler fig: replace module by module, behind a stable façade, delivering continuously. Never a “big bang” behind a curtain.
- Keep the tests: a rewrite without a regression net is a gamble, not an engineering decision.
The final criterion
A successful modernisation is invisible at launch: it shows three months later, when the team is again shipping changes in a matter of days.