You've got a couple of problems here related to your lack of communication skills. I don't know how good your code is or how bad the old code is, but let's look at what you've written here.
#1. Don't belittle others or come from a place of arrogance
What I need to do is explain that I have significantly more experience and have done this kind of work in the past with stellar results.
Stop looking at things like this. Appeals to authority like this will not win anyone over. It doesn't speak to the value of your code, it doesn't highlight any benefits, it literally just says "I think I'm the best at this so we're doing it my way". All this will do is piss your teammates off. Not what you want when you don't have their buy-in.
#2. Ease up on the technical lingo
I'm also getting bogged down with having to write a lot of 'documentation' explaining why this new architecture is better, but it's entirely technical (talking about SOLID, unit testing, dependency injection etc) so there's not really any point as management will not understand it.
It sounds like your other teammate also doesn't understand it, so change the language a little. You need this document to not only get management buy-in, but also buy-in from your teammates. You talk about things like SOLID a lot but your average non-programmer (or even older programmers) won't know what it is, so use the term, explain what it is and explain the benefits of the framework. Then use it sparingly. Do this with all the technical terminology. You need this documentation for your manager's buy-in
#3. Throw in some management point-of-view
I'm an accomplished software architect and it was a breeze. The new code is fully unit testable with dependency injection and comprehensive logging, so any bugs and problems are super easy to track down.
Stuff like this is good. From a technical standpoint. What you need to do now is translate this into management speak, which is simply following things through to their logical conclusion related to costs and return. These costs can either boil down to money or employee time (since they pay you for your time) For example:
"I'm an accomplished software architect and it was a breeze. The new code is fully unit testable with dependency injection and comprehensive logging, so any bugs and problems are super easy to track down, drastically reducing the number of man-hours required for bug-fixing and maintenance work, and therefore reducing costs involved in these labours, by both making it much easier for developers to find the problematic code and by detecting problems with new code in newer versions before they reach the next stage in the development lifecycle."
A number of other answers here also give great gems for examples of this. Work these in where you can and don't be afraid to come up with more.
#4. Address your teammate's concerns
Now, let's address your teammate's argument for keeping the original code: 'It works'. Okay, maybe it doesn't always work, but it's been relied on for some years now. You can propose to management to have a test system running with your implementation concurrently with another system running the original code. Maybe even fire off a few test-cases, including some that you expect to break the original code. This way, your teammate no longer has that argument because you've proven to everyone that your code also works, and even works better.
#5. Address unmentioned (but still important) factors
Let's throw in another argument the teammate might use: 'We all know the original code'. This is a little harder to shoot down because it is unequivicolly true, brings a cost impact that management understands and nothing you can do in your code can completely alleviate this. Your best mitigation is in your documentation, the same stuff that you say you're being bogged down by.
Therefore your documentation needs to accomplish two goals:
Persuade management of the benefits of your idea (I talked about this earlier)
get your teammates up to scratch (or at least as much as possible without trial-by-fire) on your code.
Only when you have addressed these 5 points can you get around the following problem:
The issue is that management look at both of us and don't know who to believe.