[cybadger]

Agreed, especially starting with Working Effectively with Legacy Code.

One of the hard things about what we're assuming is OP's tech lead role is that they're having to influence changes up (with management) and down/laterally (with the team). Things that might convince the team are going to be generally different than the things that might convince management. Management will probably be more convinced by things like improved lead time for changes, eliminating risk of failure, improving confidence in correctness of feature roll-out (though some of this depends a lot on the industry / domain and the incentives of management). Meanwhile the team will be more convinced by things like making their job easier or setting themselves up with more and better skills to take a "better" job down the road.

The rub with all this is that if the team doesn't like OP's changes (e.g., using source control), they'll have management cover right now. At each step it's important to show why it's better.

A way to do that—hard to tell if it's the right way without knowing more about the team's dynamics—is to make a lot of the changes for your own work. For example, set up your own test environment, develop there, then using this mystical "source control" magic apply the safely-tested changes to prod. Eventually someone will notice that you're not breaking prod as much as everyone else. ("You" here being either OP, or someone else in the same situation.)

All of this is just nuance, politics, and team dynamics layered on top of the excellent recommendation I'm replying to.