The normal situation here would be for you to work with colleagues and management to argue the benefits of rewriting it, get your co-workers on board, provide documentation, provide time estimates, divide work up and tackle it. That way you get the sign-off from managers first, discuss, various problems together, overcome them, and then coworkers will essentially have to get onboard as it's an agreed project (and there's no good reason they wouldn't, as you'd tackle it together).

From what I'm reading here, it seems like you've just gone ahead and done it (or at least done most of it), potentially alienating another dev that understands the old system perfectly well, but isn't necessarily familiar with the new libraries, tools, technologies, code paradigms and development practices you're using. Yes, there's a good argument to say he should have skilled up and stayed with the times, but in practice that often won't happen.

You then say:

Any competant software engineer would look at the code and immediately side with me

...and forgive me for saying, but that seems rather... bold. These things are rarely this black and white.

This part in particular makes me nervous:

While porting some of the code I have found a lot of bugs that I fixed along the way that should have been avoided but couldn't be as there is no way to write tests for the old code, nor is there proper error handling/logging. All signs point to the move being a good idea.

If there's no proper error handling, no unit tests etc. in the old code, then how can you verify that it behaves in the same way? How can you verify that the "bugs" you've fixed weren't actually corner cases, and no-one was relying on that behaviour? How can you absolutely guarantee that you won't introduce any critical, breaking changes with the new code? Management and customers don't really care how nice the code is, they care that it works. If it means deploying it takes longer but customers are happy and don't leave, then that's a worthwhile trade-off as far as they're concerned.

To answer the question directly here - you get management on board by demonstrating the time savings, and producing the necessary documentation and resources required to skill up the other dev and get him on board. That's not quick however - that's long & hard. In reality, IMHO anyway, you should have approached the situation very differently to begin with.

The normal situation here would be for you to work with colleagues and management to argue the benefits of rewriting it, get your co-workers on board, provide documentation, provide time estimates, divide work up and tackle it. That way you get the sign-off from managers first, discuss various problems as a team and form a plan to overcome them. Coworkers will then be much more likely to be onboard with the project as a whole since they had a say in driving it forwards. If any coworkers really don't want to do it at that point, then there's little debate to be had, as a) they had ample opportunity to weigh in on the process and b) it's been signed off by management as an agreed project, so your position is clear cut.

However, in this case it seems like you've just gone ahead and done it alone (or at least done most of it), potentially alienating another dev that understands the old system perfectly well, but isn't necessarily familiar with the new libraries, tools, technologies, code paradigms and development practices you're using. Yes, there's a good argument to say he should have skilled up and stayed with the times, but in practice that often won't happen.

You then say:

Any competant software engineer would look at the code and immediately side with me

...and forgive me for saying, but that seems rather... bold. These things are rarely this black and white.

This part in particular makes me nervous:

While porting some of the code I have found a lot of bugs that I fixed along the way that should have been avoided but couldn't be as there is no way to write tests for the old code, nor is there proper error handling/logging. All signs point to the move being a good idea.

If there's no proper error handling, no unit tests etc. in the old code, then how can you verify that it behaves in the same way? How can you verify that the "bugs" you've fixed weren't actually corner cases, and no-one was relying on that behaviour? How can you absolutely guarantee that you won't introduce any critical, breaking changes with the new code? Management and customers don't really care how nice the code is, they care that it works. If it means deploying it takes longer but customers are happy and don't leave, then that's a worthwhile trade-off as far as they're concerned.

To answer the question directly here - you get management on board by demonstrating the time savings, and producing the necessary documentation and resources required to skill up the other dev and get him on board. That's not quick however - that's long & hard. In reality, IMHO anyway, you should have approached the situation very differently to begin with.