In the codebase I maintain, this boils down to a 'gradual rewrite from the outside in' combined with refactoring bits of the 'in' where practical. You create ne

In the codebase I maintain, this boils down to a 'gradual rewrite from the outside in' combined with refactoring bits of the 'in' where practical. You create new independent code paths on the way 'in' instead of trying to make the existing ones cope with yet another use case. These tend to highlight bits of existing core code which can be refactored as isolated and testable components, typically by copy-pasting them into a separate library and updating references piecemeal. Old code hangs around as long as it's referenced, but new code doesn't necessarily have to touch that copy. Eventually the monolith's trunk gets hollowed out as useful pieces become dependencyless libraries, and the tangled knot of rotting branches, vines, and strange green things with purple lumps starts to die back as a multitude of independent and healthy trunks grow from the surrounding earth. At the risk of breaking the metaphor...