What have you tried to demonstrate time savings, fixes, money-not-wasted (on 2-hour deployments vs a click), to your management? Because, if you demonstrate "click, now we go do something else for 10 mintues and then check" vs "looking for all things, copy all the things" for 2 hours, it should make abundently clear to management which direction to go. If need be, suggest it in a meeting where your colleague is arguing against such changes: "How about we go side by side with a deployment and let X & Y decide? How about right now?"

The only things they can really understand is the deployment time, since they ask for a build and see it takes 2 hours of manually copying files etc. They can't appreciate the fact that I've often spent an entire day hunting down a single bug because the logging was broken and combined with the 2 hour deployment time it has to be painstakingly recreated on dev (and most stuff doesn't work on dev because of the way it was written). It's not really visible to them because there's no way to show time saved for unplanned events.

Yea that's why I suggested it, so they can at least appreciate the time saved on a deployment. Which in turn would up their opinion of the efforts/steps you've made. Which, as a consequence, would make them more open to your ideas and contributions without relying on the outdated developer they've known longer. It's a bit of a nasty mind-game though (take it too far and you'll definitely alianate the other dev). I suggested it so that, if you do do it, the other dev will have to start to come up with substantiated reasons as to "why not" instead "because". ;)

Perhaps worry less about convincing your change-resistant peer that change is necessary and focus on convincing your superiors. Do that, and your peer will have no choice but to fall in line. People who have been with an organisation for a long time are often resistant to hearing that something they had a part in implementing doesn't work.

Extending on @ChristianHackl, you should have brought your colleague on board with the project. You're here requesting on to use management to alienate him further. You might want to improve the interpersonal skills and ask for your colleague help instead. It is possible that you are in the wrong, independent of the technical savviness.

The most interesting phrase in this question (or rant?) seems to be as I'm in downtime. If the company thinks you are as good as you think you are, you wouldn't have and "downtime" scheduled. But since we only have one side of the story here, it's impossible to know whether you, or everyone else, is right. (It's easy for anybody with some life experience and software development experience to guess, but impossible to know.)

I got halfway through this question wondering if you took my old spot I had on a certain project a couple years ago! Then the specific technology details made it sound like no... but then you talk about the guy with seniority trying to ruin a good thing and I start wondering again.

@alephzero wrote "If the company thinks you are as good..." Sometimes that is the problem, and that seems to be what OP is asking for help with. Sometimes management and the senior people on the project are just too incompetent though. I have had multiple instances that were just too incompetent to believe, and if you knew all the details your jaw would just hit the floor.

No offense but 70% of your post seems to be about you trying to convince us that your changes are good. Honestly, we can't tell and we shouldn't care: this is a inter-personnal issue more than a technical one. I've seen my fair share of junior developers coming in to make it all "better" or "modern" (hell, I've been that guy more times than I can count). No matter how bad that guy's code is, fact is he is probably the one that understands it better. Doing any kind of refactoring without his input and warnings seems like a red flag to me.

I've no doubt you've seriously improved the code but It's not better when someone disagrees

The fact that you say that your colleague disagrees with you for the wrong reason but don't say what those reasons are, might make someone think that you're not really listening to what he's saying. I also wrote code from scratch for a company and they're still using it after 9 years. I've also got a total of 25 years of experience. I know it's painful to hear and admit, but: this alone does NOT make us good software architects. Especially when you start with the "I've got more experience, so I'm right and you're wrong" kind of attitude.

You are right about this. Just keep pushing for this and if management doesn't turn in, start looking for a more progressive work environment elsewhere. Money can be earned anywhere, but your time is wasted if you are forced to go along with bad code.

@ereOn yes I appreciate that, I should have completely omitted it from my question because there is clearly no way to demonstrate that. I updated my question because I got pretty much lynched to try and explain that I corrected a dumpster fire of a project that has everyone on board except the original guy.

@chatterone I thought I explained the reasons, the chief one being that what we have 'works'. Except it doesn't work, it breaks daily and I spend hours tracking down bugs that turn out to be trivial things as there is no error logging or handling. Also, "If the company thinks you are as good as you think you are you wouldn't have and "downtime"? Come on. I'm in downtime because there is a ton of management red tape in between phases. I feel like I'm on trial. All this speculation to try and make me the villain. By all means villify me but don't use wild speculation.

@NibblyPig The "wild speculation" will happen anyway because we can't see the code, and we have to assume you're right and the other guy is wrong taking your word for it. My point is not to vilify, just to put some perspective and trying to be objective, because you going solo in modifying stuff even in a better way because "it seems logical" is NOT what a team player does. In this case even if you're right from the technical point of view, you're still wrong in how you behaved.

That's the point though, the question doesn't ask if I improved it or not, it's a question of, 'given that I have improved things, how can I deal with someone that is now very hands-off that is resistant to the fact it pushes him out of his comfort zone?'. If you want to change the presupposition of the question you might assume that I'm actually a talking snow leopard. I think a team player does not resist change. A team player tries to understand why a person wants to do things and work with them. Honestly, I really regret asking this question in this form. I wish I could redo from start.

Note: Code that someone else wrote is always bad, no matter whether it's actually bad or not. For all we know, you might have fallen into this trap.

You need to understand that you are threatening their job security. They have spent years with this software and are the go to person to fix or change it. You are taking that away. The main thing is to include that developer in the new version and give them a key role. They have valuable knowledge of the system architecture and any issues that have been encountered so use that when building your test cases and include that developer in the process so they are an integral part of this new system. Let them learn from your experience and allow them to become a better programmer.

Yes, I've had my fair share of architecture astronauts. My dedication is to clean re-usable code that anyone can understand. @JamesCoyle that is the crux of it I think. I need to make a decision between fighting with this guy and getting him onboard, and I think I need to try the latter first before I take a more brute force approach.

@NibblyPig I'll admit I can relate to your situation. I once joined a company where there was a old developer with exclusive access to a critical part of the codebase on his laptop. He wouldn't trust anyone and top management was afraid of him. I complimented him a few times on some scripts he made and said I thought it was clever, the guy changed his attitude towards me and everyone was surprised. People skills matter more than technical skills in our field of work.