A company can take one of several approaches to motivating employees:
My guess that your current workplace used the first approach. When you do this in development you often end up retaining employees who don't have the skills or the motivation to pursue higher paying positions in different companies. These sort of people are not the types to take a plunge, and learn new techs. Not without a kick in the butt.
In all honesty, it may be far too late to reform them. I would suggest that you and your boss sit down, assess the situation from a technological and workforce viewpoint, and realistically asses your situation and goals.
First and foremost, just how poorly maintained, documented, and written is your current software? If you were to bring in a brand new team of young devs would they be able to figure it out in a reasonable time-frame? My guess is that they probably wouldn't. This leaves you in a very vulnerable position if someone were to suddenly pass away, or retire due to medical reasons, and you need to point that out. (it will lend an air of urgency to your suggestions, and maybe foster you more managerial support).
Second, just how much longer do you expect some of these people to stick around? More importantly, can you afford to keep paying them to do their job in a mediocre fashion until whenever they wish to part ways with your company? Probably not, because every day of doing things the old fashioned way is digging the company into a deeper hole.
It's good to be aware of your options, and limitations before you start making sweeping changes. Essentially, the conclusions should be that you need to change sooner rather than later, that you need to bring in new talent, attempt to train the existing team, and possibly be prepared to fight them on the changes (or even let them go) if they oppose you (the management team). Needless to say, your boss's full support is needed here.
That being said, here's what I would propose:
1. Incentives to learn new technologies
These guys are probably too old and set in their ways to change willingly. At this point you can either order them to start using a new system - which would probably lead to a lot of resentment, or offer an incentive for them to "upgrade" their knowledge.
Set up mandatory workshops to train them in using a new technology (such as GitHub). Have them sit down with you for a day of training, but sweeten the pot by offering them a free lunch, etc. That way they won't feel like they're "wasting" their personal time learning "newfangled" and needlessly complicated technologies.
You might introduce a bonus system for those who master a new technology. The rewards should probably not be monetary, but still fairly valuable. Are they into bowling or golf? How about golf clubs, or bags? Gift certificates to a local lunch hot-spot, or maybe an extra vacation day.
Hiring a couple of new, young, devs and getting them involved in the process might also help, because they would have someone around to answer questions (if their pride doesn't stop them from doing so).
The important thing for your boss to realize is that the changes will take months to pay off. In the beginning productivity might actually drop, while people are getting comfortable with the new processes.
2. Prepare to replace them
Unfortunately some people just don't want to change. They might scoff at your training sessions, and scorn your efforts to bring them into the 21st century. At that point you stop offering the carrot, and reach for the stick.
You may want to hire a few young devs, set up a new programming team in parallel, and get them to start converting your software to a new standard (or implementing new projects strictly in new languages, etc.). This is a very aggressive move, however, and would send a rather threatening message to these older guys.
However, based on how resistant they are to change, and how vulnerable your code base is to their specialized knowledge, you may wish to do it anyway.
The downside here is that as your workforce grows, and so will the company's costs. The atmosphere in the office might also become rather strained depending on how you handle it all. However you can't back down from your course of action. Discuss possible disciplinary actions against devs who outright refuse to follow the new processes. Do they get verbally cautioned? Written up on the second offence? Are you prepared to fire one of them? Discuss these worst case scenarios and reach an understanding. The worst thing you could do is threaten someone that it's your way or the highway, and then fail to follow through with your threats. You will lose all authority if you do this.
The best approach is likely a combination of these two suggestions.
Encourage these guys to pick up new skill in a positive a manner as possible, but also hire new devs and implement all new projects using modern approaches.
That way you're actively bringing the company's architecture into the present, but you're giving these people a chance to upgrade their skills, rather than simply firing them.
The company's costs will rise dramatically for a period of time, however in the long run they will succeed in renovating their processes and upgrade their technologies.