Should You Rewrite a $20M Legacy Codebase? Insights from a Nightmare PHP Project

Advice 1: Don't rewrite, just quit

Many argue that a full rewrite is a bad idea, especially when the business is thriving; the code generates over $20 million annually, so from a commercial perspective it’s a cash‑cow that doesn’t need replacement. Executives may view the messy 2003‑style PHP as acceptable because the revenue outweighs technical concerns, making a rewrite a political as well as technical challenge.

Advice 2: Avoid a complete rewrite

Some suggest incremental improvements instead of a total rewrite. Options include forking the repository and delivering small features, introducing modern practices such as Git, code comments, branch testing, self‑hosted CI/CD, and adding tests before any database migrations. Updating the front‑end with a modern framework can boost performance and user experience, allowing the back‑end to be refactored gradually.

Fork the codebase and release incremental functionality to gain market advantage.

Adopt Git for version control, add comments, create feature branches, and set up CI/CD pipelines with automated testing.

Modernize the front‑end with a contemporary framework, then progressively refactor the back‑end as test coverage improves.

Advice 3: If you can't rewrite, consider leaving

When leadership is unwilling to invest in a rewrite or the team lacks full support, the recommended course may be to find a new job. Some contributors share personal experiences of successfully rewriting a similar $5 million PHP application to Django over two years, starting with small “20%‑time” projects, gradually redirecting traffic, and eventually gaining executive backing. However, without such backing, staying in a toxic legacy environment can stall career growth.