So, first thing: Legacy code is a profit centre for the company. All NRE costs have been amortized over the years, and the company counts on it to make money ev

So, first thing: Legacy code is a profit centre for the company. All NRE costs have been amortized over the years, and the company counts on it to make money every year, money which actually goes to fund those other mostly hare-brained projects. The work you’re doing is often more important to the company than the shiny new port which has a high risk of failure. The real problem here stems from the promotion cycle that over-rewards new features and under-rewards maintenance work. This is uniquely a software problem as in any other industry, replacing the plumbing is extremely well-rewarded. Since you are intimately familiar with the flaws in legacy code, you are uniquely positioned to think about what a refactor or a complete rewrite on a different framework, or a different language, or even a new platform, would look like. Whatever you come up with would be a great step forward for the current product. Once you have a vision, sketch out a strategy and present it to your manager. Then, this is key, regardless of what the manager says, start working on it on the side. Bring that vision into your legacy code either as piecemeal updates or wholesale as a brand new prototype. Once the prototype is working, present it to your manager. Once again, the key bit is that it does not matter what the response is. Keep refining it, because ultimately you know better than they do what legacy code needs. Ultimately legacy code will becom unmaintainable due to deprecation, platform switch or other factors. That’s when your prototype becomes the fastest replacement and gets you the promotions. In short, you must create your own new work. Don’t wait for permission. Once you are successful at this a few times, the company will give you a much freer hand to implement new features wherever you see the need, since you have proven yourself to know better.