The $30M Project That Died Because Nobody Owned Cleanup

This is a cautionary tale for anyone sponsoring a large transformation program based on something I saw a few years back.

The setup: a complex Salesforce org on Industry Cloud, replacing a 10-year-old legacy system. A well-known implementation partner. Strong architects. Good Product Owners. Real budget. Real executive attention. NOBODY in the project did a bad job individually!

Three years and tens of millions of dollars later, the org was decommissioned. I was part of the team that recommended killing it. (One of only two times in my career I recommended Greenfield)

The root cause wasn't technical. It was a measurement problem.

Every team was measured on one thing: features shipped toward parity with the old system. That metric drove every sprint, every release, every prioritization call. UX, Cleanup or refactoring were never on that scorecard so they never got resourced, never got sprint time, and never got defended in planning.

The processes, architecture and implementation standards evolved over the years, which is normal. What's not normal is that nothing old was ever retired. Legacy fields, layouts, automation, and code accumulated layer on layer, because removing them didn't move the one number leadership was tracking.

This is what compounding technical debt looks like in practice:

1. Logic spread across the org with no single source of truth
2. Architects designing around broken legacy code instead of fixing it
3. Core business processes that became harder to explain with every release

4. Engineering time increasingly spent managing complexity instead of building value

No single decision caused this. Each one was locally rational: "ship first, clean up later," "out of scope," "doesn't move us toward parity." The damage was cumulative, and cumulative damage is invisible on a sprint-by-sprint dashboard. That's exactly what makes it dangerous for management to oversee by the time it shows up in velocity or defect metrics, the cost is already sunk.

By the end, the Org wasn't just hard to work in. It was not economically salvageable. Killing it and starting over was the financially sound call.

The takeaway for leadership:

If cleanup and refactoring don't have a line item, a percentage of every sprint, and someone accountable for them, they will lose every single time to a feature backlog because features show progress and cleanup doesn't, until the day it's the only thing that matters.

My estimate, based on this and comparable programs: roughly 15% architect and development capacity dedicated to cleanup and refactoring throughout the program would have been cheap insurance against a $30M write-off.

Cleanup isn't overhead. In a multi-year transformation, it's the mechanism that keeps delivery possible at all.