What's proposed in the article is mostly what I would call, low level refactoring. It's what's done almost all of the time. Group some things together, split so

What's proposed in the article is mostly what I would call, low level refactoring. It's what's done almost all of the time. Group some things together, split some things, use better names, move to other files etc. Technical debt on the other hand originates more from a design that does not fit the application anymore, because of added features or change of goals over a latge time span. That's where what I would call 'real refactoring' needs to take the stage. Document/draft the current architecture as well as an architecture that fits better the purpose of the application. Work out a path to move from one to the other. Usually but not necessarily, this path is executed in steps, while keeping everything functional. New skeleton / middleware code is needed, some parts need rewriting, some parts need moving, some parts need deleting.