Adding unit tests is often hard to do with legacy code because it wasn't designed to be granularly testable. It is often better to figure out what interface that code provides and then add tests of that layer of abstraction. Then, you can refactor more safely so the code is unit-testable.
After all what you really care about is the behaviour of the system. It can be counter-productive to unit test pieces of legacy code because you may end up refactoring things at a higher level and breaking all your unit tests.
If it's clear that a piece of the legacy system stands on its own as a "unit" and has reasonable interfaces then by all means add unit tests to that. The biggest value though IMO in a "legacy" system is to add system level tests. Those are often easier to put in than unit tests, will catch problems involving multiple components, and will teach you about how the system is supposed to behave.
For me this is clearly the way to go. If you add unit tests to a bad designed interface you are only making it more difficult to fix. Now you don't only need to change the interface but also the tests increasing your technical debt.
System tests are the best cost/value tests. You only add unit testing to stable code that is not going to change often.
System tests cover the same code that the unit tests. Its only disadvantage is that - maybe - it will take more time to know what is failing when something fails as they cover a broader amount of code.
It is really nice because its chapters are arranged around specific problems you will encounter wrapping existing code in tests so you can easily find the write chapter via the table of contents.
"Not shipping" and "ensuing mass layoffs followed by bankruptcy" are still considered feasible.
I kid, I kid. A few thousand lines of code in isolation? Piece of cake, I can grok it within the hour.
Ten lines of WTF intertwined within a multi-million LOC codebase making judicious abuse of reflection, TLAs, and layer upon layer of misnamed abstractions which do something subtly different from what you expected - using three technology stacks spanning three decades of changing idioms and trends in software development - written in a 'mission critical' culture where bugs are intentionally kept as backwards comparability features? Three people will claim to understand the code well enough to make changes within a week: The rookie, the madman, and the asshole who wrote it. If you're lucky, none of them still work there - based on the number of bugs increasing when "fixes" are applied, it's clear none of them do, or ever did.
Priding myself on being only half mad, I will claim to understand 5 out of 10 of those lines within a week. If I'm lucky, they'll even be the 5 lines I need to modify for your feature request. Based on my vague understanding of the few tens of thousands of lines of code these 5 lines interact with, I can assure you I am half certain[1] that I probably didn't break anything [2].
[1] Read: Half uncertain [2] Read: I'm assuming our QA team are not mere mortals, but are gods, and thus have at least a 50% chance of catching any bugs I introduced.
The real difficulty is that you've no way of knowing whether the WTF you're looking at is inappropriately placed (and completely undocumented) business logic, an actual bug or a seriously hacky workaround for a bug in a completely different area of the code. If a bug, it may well be itself worked around by a seriously hacky fix somewhere completely different, which will break horribly if you fix the issue here. If it's a fix or especially if it's business logic then then it's even odds that it's not required any more.
Fortunately the codebases I work on are generally <1MLOC, <10 years of tech churn, had at least some decent coders helping keep technical debt from spiraling completely out of control, with management that will give them the time they need to manage that technical debt. So it usually takes more like 50 lines of WTF to confuse me to the point of needing over a week of basically pure analysis to untangle things.
But I don't have enough time to perfectly understand the entire codebase and all it's dependencies. And it doesn't eliminate the need to manage the expectations of management. If they don't understand where things are at, even good managers will over-promise in their contracts (bad - enjoy crunch, slipped milestones, and missed payments!), under-promise in their contracts (bad - leaving money on the table), mistime their marketing campaigns, mistime their hiring pushes, plan the next project to start when the current one is just ramping up, fire the wrong people, hire the wrong people, hurt morale with unrealistic expectations... all kinds of nasty stuff.
Especially if you have to write them in COBOL.