That depends. It sounds like your veterans are burned by the similar lip service to deprecate this codebase.
Are you a bad enough dude to rise up as a leader for these people and help get them out of the rut that you're now experiencing? (And get yourself some leadership bullet points for your résumé?)
Let me toss out a couple of definitions that I subscribe to first before I continue:
Lacking a comprehensive suite of automated unit ("small"), functional ("medium"), and integration ("large") tests is a necessary and sufficient condition for code to be called legacy.
Code is called deprecated if and only if there is an active, expedited push to remove it from production and, if dependencies on it still exist, replace it with something functionally equivalent. (This second part is crucial.)
Frame the conversation in these terms.
With that said, I have a couple of questions:
Do managers make the technology and risk management decisions in your organization? If so, your first priority is to find some way to usurp that from them as an engineer with help from your veteran cohorts.
Do you have any experience writing those three classes of automated tests I rattled off here earlier? If not, this is your perfect chance to develop that skill. It just so happens that this carries over into your area of interest, and it's a very good discipline to get into.
Writing tests like that establishes a certain sort of contract about how the software should function. Integration tests, ideally, exercise its functionality in the context of its inter- and co-dependent systems. Meanwhile, functional tests, with a similar ideal, exercise its functionality in the context of intra-module dependencies within the same system.
With those two things there, you'll be able to make "right around the corner" more of a reality because you'll actually have a metric to use to measure how "done" you are with a drop-in replacement.
(And, along the way, since you're already perceptibly breaking things, you can deliberately break some things but use those failure modes to write integration tests that further boost your confidence that you're getting there! Sneaky!)
Unit tests, in contrast, help you to cross the last mile of maintaining what you currently have as requests to change things come in. To use your language here, it'll help make the process a lot less stochastic, at least in terms of management perception. Your tests will fail before anything happens in production.
If you stay at this organization, your personal goal should be to learn how to write those three classes of tests and to get good test coverage around it all.
Then again, if you can't usurp those things from management, run.