Sam spent the last few years at a non-profit with a series of refactors and migrations/rewrites with his team. For example:
- Rewriting the C# API, first to unit of work (complete rewrite), then refactoring to CQRS
- Adding ES6, followed by TypeScript, to the AngularJS front ends
- Migrating the front ends from Gulp to Webpack and from Bower to npm
- ngUpgrade (still in process when I left)
- Determining whether to update to Webpack 4 or move to the CLI later
- Several large data structure refactor projects initiated by the business that affected the entire stack (from SQL to Angular)
They had to evaluate the risk of maintenance vs the risk of updating vs the risk of rewriting. They used a mix of determining the business impact, the technical debt, and developing proof of concepts to figure this out each time.
I feel like this is a constant issue teams face, especially smaller teams that are not working for software companies (though software companies, of course, do this as well, but are perhaps more driven by end-user needs/sales).