I was in a very similar situation. Eventually I had to leave the company, but that may not have been the best idea.
As Adel points out, you're going to see this in a lot of companies. When I left work, I started picking up some Freelance work to make ends meet and working under some of the contacts I had made. Out of the 7 Companies I've developed for thus far, none of them had any documentation, multiple versions of software scattered around the business and didn't even understand what a long-term roadmap was. The guys with money do not work with code, so they don't care about any of that stuff.
What I tend to do, if it's a fairly small project that has just became overcomplicated with time, is try to convince the client that it would be better to redevelop from scratch. Then put those documents together myself and comment the code. There's a lot of loopholes you're going to have to jump with this though.
First of all, as you've noticed... people do not like change. They like sticking to the comfort of old technologies, new stuff requires effort to learn. If you can show them that their part of it will remain practically the same, that will soften the blow. Keep the same UI elements, keep the same layout, keep changes with how they interact with the software to a minimum. (I also tend to throw out the words "Future Proofing" a lot, management seem to like those words. They tend to imply that they won't need to invest as much later down the line, which is true if you do it right).
Secondly, companies will always have doubts about something untested VS something they know works. There's a risk element, you need to keep this to a minimum and pull every fact that you can in your favour. If I come up against someone really reluctant to change, I tend to make them a little power-point with the strengths of the change. If you want to switch from some ancient language nobody uses any more, make sure the higher ups understand why everyone else has already switched to these new technologies. Use real-world examples to prove that it works.
How much quicker will it be to implement changes?
How many limitations will this remove?
How much more secure will the software be?
How much cheaper will future development be?
They're not going to care one bit about how much easier it is for you, or how much it will help you develop as a programmer... they want to see what benefits it has for them and the bottom line.
Lastly, make sure there isn't a genuine reason for it. One of the companies I developed for were handling logistics on behalf of another client. I wanted to change their software from Visual Basic 6 to .NET 4.5, only to find that their client required access to the code, and their tech guys only worked in VB6... so that was a complete no-go for upgrading. This stuff happens and then you just have to grin and bare it. You might find other technical reasons for this as well, such as having to interact with ancient software elsewhere in the business.
Also one last note. If you're going to write out documentation, make sure it's okayed with your superiors first. Even though it can be invaluable to programmers, there are companies that will see that as a major waste of your time and their money.