I don't mean migration in the sense of switching databases or rewriting in another language. I mean that a codebase rots if nobody maintains it. Deprecations, warnings, upstream changes — each is cheap to handle the moment it appears, often a 10-minute fix (let's say 'in average'). But plenty of teams never catch them. No real CI/CD, no culture of reading changelogs or acting on warnings. So it piles up silently, and then at some point — usually when an infra or security team shows up with tickets — the whole accumulated pile lands on one person at once. Often a new hire or a junior who's never seen the code, with no record of why any of it is the way it is beyond git blame, a stale changelog, and a few dead chat threads. What I think gets underestimated is that clearing it all at once costs far more than the sum of the small fixes would have. The problems tangle into each other, and the context that would let you separate them is already gone. So I'm trying to learn from people who've been dropped into this. What did you actually reach for, and what worked — tests, diffing output before/after, shadowing prod traffic, or just running it and hoping? Did anyone try LLM agents, and where did they genuinely help versus confidently make things worse? (I know of an Angular case where the agent kept patching a function it assumed was the problem, and after a couple of failed runs invented its own workaround — when the correct approach was in the docs the whole time). Just time spending. If you can ballpark it: how much worse was all-at-once versus incremental — 3x, 10x? And one thing I keep wondering: when you were reconstructing a system like this, what were you missing more — a description of what the code does, or of what someone meant it to do? Those feel like two different problems.