How to sell a big refactor or rewrite to the business? — Ivett Ördög

Small refactors can be done under the radar as part of feature work - no need to ask for permission if impact is minimal

Large refactors need business buy-in - verbalize customer value and business benefits to get approval

Incremental delivery with continuous customer value is more likely to succeed than big-bang rewrites

Split large refactors into smaller chunks that each deliver value, rather than stopping all feature work for a long period

Look for ways to quantify and demonstrate business impact - faster imports, better performance, reduced errors

Consider creating a parallel improved version rather than rewriting existing system (like VS Code and Prezi Next examples)

Focus first on fixing the most impactful problems that affect the most customers

Continuous deployment and incremental improvements lead to better outcomes than long periods without releases

Don’t try to do perfect design upfront - start with MVP and improve incrementally

Ensure refactoring efforts align with actual customer needs and usage patterns rather than theoretical improvements