Nothing in software sounds as tantalising as getting the next latest-and-greatest framework update which is "backwards compatible" with your existing code.

I have never seen this work correctly and there are reasons why it can't.

In general:

  1. If you are making any significant additional value in the new framework, it cannot possibly be backwards compatible without leaving a tonne of legacy interop "the thunk layer" or attempting some new bridging code with all the bugs or imcompatability it brings.
  2. A major upgrade should be considered as a major piece of work and effort made to consider the cost-benefit of doing so. In many cases, organisations don't have the will or means to invest what is necessary to keep things up to date so don't fool them into thinking they can get this all for free. You will only give them new bugs they didn't have before.
  3. Software sounds so easy to continuously update and upgrade but how many of us have actually managed this? Of course, we can do this to a point. Add a few more features and what have you but even something that sounds relatively easy like replacing Bootstrap v3 with v4 in itself could be 3 months work. I suggest that we allow people to keep their old crappy code running on their old crappy frameworks and let them be judged on it and the cost to maintain it. Just like an old car, if you don't want to invest in a new car every 5 to 10 years, you have to pay more and more to get support and people can see it's a junker.
  4. Backwards compatability is a burden that no developer should have. Changing web forms to MVC was not a big deal in dotnet because they were completely different. However, dotnet core came along with netstandard and now .Net 5 (whatever that is) creates a terrible mess for Microsoft and for Developers. What self-respecting framework should have several hundred open issues, many of them about "this used to work like this and doesn't any more" you then read the responses, which are usually, "we are unlikely to fix this now we have given you the new framework" or "we are not sure how to fix this in a way that works with both frameworks". Dotnet cli, SDKs, builds tools and nuget have all been given severe bugs, many still unfixed, that wouldn't exist if they didn't have to support the old frameworks.
  5. Creating separate frameworks without backwards compatability forces the vendors to carefully consider their value proposition. Look at Windows Vista. It was rubbish and ill thought-out so people didn't buy it. MS were forced to eat humble pie and produce Windows 7 which was many times more stable than Vista ever was.
  6. Developers definitely need to be more professional in general. We can help push this by making them good at understanding functionality and writing good tests or documentation. If you force people to rewrite pieces of code to use a new framework, they won't do it unless they have the correct supporting systems to prove their new code works the same way as the old code. If Developers are better at verifying existing code, they can write it in the new framework (it might even look the same in some cases), which helps us understand that software systems do not stay still, they update and evolve over time and most of us won't be working on 10 year old software anymore as people realise this.
  7. You can avoid a load of pointless arguments about the fact that version X was better because it did this and that. Instead, each framework stands on its own merits. The new framework doesn't support X and Y but it is 10x faster than the previous one. Pick what is most important to you.