Yes.... Just one example if you are curious. At some point NGCC broke parallel builds. https://github.com/angular/angular/issues/38875#issuecomment-693634786 ht

Yes.... Just one example if you are curious. At some point NGCC broke parallel builds. https://github.com/angular/angular/issues/38875#issuecomment-693634786 https://github.com/angular/angular/issues/38875#issuecomment... The project I'm upgrading is a library used by other downstream projects. My goal was to release a working version of the library for each Angular release. However, I could never resolve this particular issue and just had to skip that version of Angular. Another common problem I ran into - dependencies that support, for example, ng11 and ng14 but not ng12 or ng13. So your options are to skip that version of Angular, try to replace or remove the dependency, or beg the author to add support for a version of Angular that is years out of date. And material components version 15 has a breaking change around custom themes that means either I cannot upgrade to that version, or I have to completely rewrite the entire theming functionality within my project. So yes, I can run ng update @angular/material@15 and migrate the code easily, but that doesn't mean "it just works". To be clear, I'm not complaining about Angular, or anything else in particular here. In my case, the decisions of the original authors caused upgrading to be more difficult than it needed to be. My point is, without knowing the details of any particular project, it's easy to see how upgrading across several major versions can quickly turn into a nightmare of rewrites.