A team schedules a large refactoring project and it is repeatedly deprioritised. What approach actually gets refactoring done?

Why the project approach fails

A large refactoring project has no business outcome to defend, so it competes with features and loses — every time, in every organisation. And when it is funded, it is a long-running branch that diverges from a codebase that keeps changing, which is how these efforts consume months and are abandoned.

What works

1. Refactor as part of feature work, in the area being changed. The code you are about to modify is the code whose structure matters most, and improving it is justified by the change you were making anyway. This concentrates improvement exactly where change frequency is highest, which is where it returns most.

2. Small and continuous, merged frequently rather than accumulated on a branch. A refactoring that ships daily never diverges.

3. Separate commits for behaviour-preserving changes. A commit that only restructures is reviewable and revertible; one mixing restructuring with a behaviour change is neither.

4. A ratchet, not a sweep. New code must meet the standard; existing code improves when touched. Automated checks enforce the boundary — coverage, complexity, dependency direction — so the codebase can only improve. This is what makes improvement durable without a project.

5. Reserve a fixed proportion of capacity, protected by policy rather than negotiated per item, so it survives roadmap pressure.

When a dedicated effort is genuinely justified

• A migration that cannot be done incrementally — though these are rarer than claimed, and the claim is worth challenging.
• A change too large to be safe in pieces, which usually means the codebase lacks the tests to make pieces safe. That absence is the first thing to fix.
• An area nobody is otherwise touching that must change for an external reason.

Even then, structure it as a sequence of merged increments rather than a branch.

The prerequisite

Tests that make restructuring safe. Refactoring without them is rewriting with optimism. If the area lacks coverage, adding characterisation tests — capturing current behaviour rather than intended behaviour — is the first step, and it frequently constitutes most of the work.