The best practice is to not learn a new framework. Only learn the new concepts (technical and UX, if there are any) and if there is no noticeable benefit do continue using old framework.
In many cases new frameworks do not bring improvements to a degree that switching is worth it. They often do either obfuscate it or don't realize it themself, but most new frameworks do not invent any new concepts, they just dress existing (often old) concepts in new clothes. Which sometimes _can_ be a major improvement of UX but very often are not.
In the specific examples I’m thinking of, it’s transitioning from a single-threaded, non-async infrastructure to a multi-threaded and async infrastructure in a new language. We had to learn a new technology stack for that; and, frameworks, among others, are a required step in that.
I’ve also had to do “best practices” around things like introducing grafana or whatever to our stack, and what the metrics should look like.
The best practice is to not learn a new framework. Only learn the new concepts (technical and UX, if there are any) and if there is no noticeable benefit do continue using old framework.
In many cases new frameworks do not bring improvements to a degree that switching is worth it. They often do either obfuscate it or don't realize it themself, but most new frameworks do not invent any new concepts, they just dress existing (often old) concepts in new clothes. Which sometimes _can_ be a major improvement of UX but very often are not.