[user5994461]

>>> It often is a task of it's own. It's not always "low-level work", sometimes it's directly replacing key components in a huge chain of events that all need to be modified to accept your refactor. It really depends on the codebase, features you're developing, nature of the business engagement and so on. There is also risk in a refactor, especially if it's heavy in business logic.

And that's why refactoring has a terrible reputation and developers can't be trusted. Now you're talking about replacing key components and altering the business logic under the pretext of refactoring.

This should NOT be called refactoring, this should be called replacing key components and revisiting the business logic.

Of course, management doesn't want that to be done without justification.

[watwut]

Refactoring may change how business logic works internally without changing anything in input/output or features. If you need to change how key components are implemented, without changing what they do, then you are refactoring them. Changes may be big internally, but it is still called refactoring if features don't change.

[adrianN]

If your code developed a "god class" that does everything and should be ripped apart there isn't much you can do about it except changing core parts of your project.

[ehnto]

I don't mean changing business logic, refactors have to retain business logic still, and the risk is that the developer gets that wrong.

It sounds like you're not getting good communication from your developers or you're misunderstanding them when they say they need to refactor. Refactor is still the right word for it, but you need to find a way to communicate the extent of the refactor.