I've had the same debate at every company for which I've ever worked, and the setup is always the same. Legacy tools are in place that technically get the job done but are annoying, but newer programmers are calling for new methods and tools. Some of the older dogs and management don't want to change, citing the overhead and cost of switching gears -- while the voices of change insist that a smoother, faster, easier, and more stable iteration process awaits at the end of that overhead. On healthy teams this leads to a lot of passionate, respectful debate. On unhealthy teams it spawns gnashing of teeth, finger pointing, and name-calling.
Ultimately, it comes down to management making a decision. The problem is that the people that manage programmers often have no idea what it is that programmers do. (If your managers do understand your work, consider yourself lucky.) What managers do understand, however, is their bottom line. They understand that after they ask you to complete a task some variable amount of time passes before you walk back into their office and report that it's done. As far as they know a genie comes down from on high and rolls magical dice to determine how long it will take, so they're open-minded but skeptical when you insist that the new ways will increase your iteration hertz.
The key is that there is no genie. Your iteration process is directly dependent on your tools and process. Let's consider some of the arguments seen by progressive movements within long-standing teams:
Argument: What we have already works. Why do we need to change?
Rebuttal: It technically works, but does it really work? I've worked at places with house-of-cards CMSs that could reliably spit out a page if you didn't forget any of the 85 things on their gotchas checklist, but I contest that hardly counts as working. If your programmers, despite trying their damnedest, rollout new bugs every fifth deployment because things are so coupled and tricky then your CMS does not, in fact, work.
And similarly, do you know what works really, really well? Established frameworks and CMSs. They have hundreds of unit tests, hundreds of developers contributing tens of thousands of man-hours, and potentially millions of websites (in the case of Wordpress, for example, which runs ~17% of the Internet, and >50% of all CMS-using websites) already finding and reporting all imaginable edge cases. Your company would go bankrupt trying to recreate that level of stability.
Argument: We all already know the current tools. If we switch to XYZ we'll have to start over!
Rebuttal: True, you do all know the current tools. And true, if you switch you'll have to learn the new stuff. But did anyone know your completely customized, in-house system when they started there? Of course not. They had to be trained on site, consuming not just one, but at least two people's time for a number of weeks.
What documentation did they read about low-level functions and classes? Likely none, because small-time shops are notoriously bad at commenting their code. But if by some stroke of near-magic there is documentation on your low-level stuff it's there because someone in the company painstakingly wrote it and is maintaining it. What a time sink! You know what's perfectly commented and documented without costing you a single penny? Every single popular open source framework and CMS in the wild.
Argument: The more new technologies we add, the longer it will take to ramp-up every new employee!
Rebuttal: This argument is errant for two reasons.
First, it's simply not true. If you think you can train a new hire the intricacies and gotchas of your proprietary system faster than you can teach them Django and REST, then you truly do have no idea what you're missing out on. Hell -- you likely could teach yourself Django and REST faster than you can teach new hires your pasta system.
Second, you'll never find a candidate well-versed in your system. Ever. But you know who wanders the streets in packs, well-trained and completely ready to hit the ground running? Experienced Wordpress, Node, or Django developers. They've already read all the documentation that you didn't have to write, they've built and deployed projects in the frameworks in their underwear on Saturday mornings, and they're altogether already pros. That means less training time, earlier productivity, and possibly even hiring in experts that can show you best practices you had no idea existed.
Argument: But we've spent so much time developing our system. We can't just throw away all that time!
Rebuttal: See the definition of sunk cost. This is a problem faced all across business and everyone recognizes that it sucks. The only thing that sucks more than incurring sunk cost is to keep sinking more value into the same well. The time to turn the ship around is the moment the problem is recognized.
Instead, chalk up existing code as a long-running learning exercise. What did you learn? To not re-invent wheels that already exist. Or maybe you started before Wordpress and great frameworks became popular and you really had no other options. If so, that's fine, and kudos for building something that was likely cutting edge for its time. But if your first line of code was written in 2004, it's almost certainly time to start clean for new projects.
The next time you're considering spinning up a new project with the existing system, crack open a Django or Rails book instead. Or, if you're really feeling adventurous, dive into Node.js.
Argument: We have too many lines of code. Converting to something else is completely unrealistic.
Rebuttal: No it's not. Major websites with way more lines of code than you have switched midstream, so it can be done. It is possible that you're not up for the challenge, but be honest with yourself and admit that's what your hangup truly is. It can be done.
Also worth noting is that you don't execute this transition in one single strike. It's a gradual process with a temporary period of duplicated effort until you can finally switch a bit and serve your website/application from the new tools. If you attempt to chew the entire sandwich in one bite you'll only hurt your jaw and end up spitting it out -- so don't even picture that fearful image.
Switching frameworks and tools isn't about simply using the newest, shiniest thing Google can find. It's about getting your technology out of the way so you can focus on building your projects. If you spend lots of time constantly building add ons to your CMS, you're doing it wrong. That work has already been done and open sourced. Your main task should be integrating those tools together so you can complete what makes your project unique.
If I could impart one closing nugget it's to make decisions about what will optimize your team when its running on all cylinders. Don't let the fear of increased ramp up time, or of a temporary overhead phase, steer you away from refining your process at its best. Over the months and years, that's the phase where you'll be spending the vast majority of your time so that's what you should be striving to perfect.