In ancient times, I was placed on a legacy project that was, without exaggeration, 30 years old. Much of the team on that project had been on it for just as long. These are not inherently bad things. There is great value to a team with rich experience and intimate project knowledge. The danger is in technology, tooling, processes - basically, attitudes - stagnating unnecessarily despite easy access to free education and resources. In these situations, I find myself wondering if there is a problem, and what its depth must be.
As I said, the age of that project and the developers assigned to it was not, in itself, a problem. But when I joined, the team had still not transitioned to or even considered source control at any point in their 30 year tenure. Keeping a project alive for that long without implementing source control struck me as both miraculous and dangerous. Not to mention wasteful, considering the process overhead in manually managing a large code base among a growing team of many developers. The merge process for the flagship product at the time I left the company was still to literally copy the entire code base onto a network drive with your new changes in it. The team lead would then pick it up and manually copy your changes among his own for the next release.
Now I suspected, despite being a junior on the project, that this might have been a process that was inefficient and error prone. I voiced my concerns early, and gently, but with no lack of gravity. Management responded with confidence that their project was not suited to Git. Besides, they said, the transition would be too much of a risk and they couldn't afford it. I carried out a proof of concept in a virtual machine to show both that the project was suited, and the transition only took me a couple of days. They still refused to make an attempt at picking up Git (or any alternative), saying the project was not suited, and the transition was too risky. At that point, all I could do was to stare blankly and start looking for a new job.
Management's hand was finally forced, though, by the growth of the team. Including me, the team nearly doubled in size, in about half a year. The old process of copying gigabytes of project code and assets back and forth for every significant change was no longer sustainable. The project lead, however, continued to fight the transition to source control. He voiced concerns over "poor reliability," and worried that it was "too slow" and restrictive in its capabilities. When pressed, he admitted not reading up on it, understanding how it works, or taking a look at my proof of concept.
Hey, I'm not a project lead, let alone a world-renowned thought leader or technologist. But if you genuinely believe source control is inferior to copying a .ZIP of the entire code base to a network drive every time a change is made, and you are not willing to learn what source control is before making that judgment call, then I am not sure how to help you.
To be fair, I was able to convince this team to make the transition to source control, with effort, consistent pressure, and demonstrations of my proofs of concept over a period of about a year. I can't count how many times the word "cool" came out of the team lead's mouth when he finally saw what Git could do. Their manual merge process of up to multiple weeks (not kidding) was reduced to the typical hour or less that it takes to review, discuss, and merge a pull request on GitHub.
Newfangled tech might not be right for your project. But it's worth knowing for yourself.