Legacy doesn't always mean bad. It may have an older architecture or have some constraints that aren't always a problem. I work a few different product designs but they almost all come from a legacy product. It's not a bad legacy design, it does what it's supposed to within the environment it was designed for. Customers still buy the legacy design. It's cheaper and doesn't have the flexibility or add-on features of the newer designs so if they don't want them or can't use them, they'll buy the legacy product.

>”we know it’s old…”

I think the point I was trying to make is if a substantial amount has been changed, on what basis is it still considered “old”?

If every plank and nail of the ship is replaced during it’s voyage, is it still the same “old” ship that disembarked?

Philosophical Gedankenspiele aside, there are differences between a ship and software. I can best speak to the software side, as I'm not a man of the sea. For once, a ship has to carry its own weight, so you cannot without limit load more and more onto it, or replace parts by heavier parts. With software "evolving" (rather poor but common terminology, I know) in tandem with new hardware, on the other hand, programmers get more space and faster processing every year, so they are less constrained and can postpone radical but scary/risky refactoring. There is no force to radically take out old code, you can comment out a bit here and there and add lots of new fixes and extensions, increasing complexity and technical debt every year, every decade. The OP also mentioned underfunding of the organization, typically the budgets only permit small incremental changes to "keep the ship running": there is no possibility to start a fresh/modern implementation with a separate team in parallel due to the mind-boggling cost.

It would be interesting to run a diff of snapshots of any software in 1960 and its 2060 version, if e.g. SABRE or the IRS system may last that long.

And its worked for 60 years. I would take that over anything else.