You may have answered your own question without realizing it:
These projects are still utilized in production environments (without issue) and have new features implemented on a yearly cycle.
If that is indeed the case, the implementation is probably not as bad as you think it is. If the software works and is relatively easy to maintain, you've nailed it. On top of that, if you can easily add new features without drastic structural changes, then you've really nailed it.
You will always look back on yesterday with what you know today and decide that yesterday is somehow inferior to today. That's what we call growth and improvement, however it doesn't imply that yesterday in some way needs to be fixed.
Why, oh why would you spend any considerable length of time making a maintainable, extendable and functional program be exactly the same thing as it was when you started? Will there be any obvious gains to users that aren't measured in millionths of a second or lines of code that they rarely (if ever) see?
If, during the life cycle of the program you realize that deprecated methods or functions make the existing design not make as much sense as it originally did, you might have to make some adjustments. You might also need to introduce a feature that eventually justifies going back and doing a lot of re-factoring.
Don't go re-factoring something in production just for the sake of re-factoring. The whole goal is to write code that doesn't have to be drastically changed in the future, and it looks like you hit that goal. Why short circuit a success?