A CFO watching a Business Central implementation slip its third go-live date faces a genuinely hard question: is this project fundamentally salvageable with the right intervention, or has it accumulated enough damage that starting over — expensive and demoralizing as that sounds — is actually the faster path forward. Getting this call wrong in either direction is costly: rescuing a project that needed a restart wastes more money chasing a bad foundation, and restarting a project that only needed stabilization throws away real, usable work.
Here's how to actually tell the difference.
The Question That Matters More Than the Timeline
A missed go-live date on its own tells you very little — projects slip for all kinds of ordinary, recoverable reasons. The more useful question is whether the foundation is sound: is your core data model, your configuration approach, and your understanding of your own requirements fundamentally right, just incomplete or behind schedule? Or is the foundation itself flawed in a way that any further work gets built on top of a problem rather than around it?
Signs That Point Toward Stabilization
A project is usually a stabilization candidate, not a restart candidate, when the core configuration decisions were reasonable given what was known at the time, even if execution has been slow or communication has broken down. If your data migration approach is sound but incomplete, if your requirements were documented reasonably well even though implementation hasn't caught up to them, and if the team — even if it needs to change — was working from a defensible plan, that's a foundation worth building on rather than discarding.
Similarly, if the specific problems are concentrated in identifiable areas — a particular module never got properly configured, testing was skipped or rushed, training never happened — those are fixable gaps in an otherwise sound project, not evidence the whole thing needs to be undone.
Signs That Point Toward Something More Drastic
The more serious signal is when the core data model itself doesn't reflect how your business actually operates — not a configuration gap, but a fundamental misunderstanding baked into the foundation from the start. If nobody currently involved can explain why key structural decisions were made, or if unwinding a series of workarounds would touch nearly everything else in the system, that's a different category of problem than a project that's simply behind schedule.
Widespread data quality issues that trace back to garbage going in during migration, rather than isolated data entry errors, are also a stronger signal — bad data compounds silently and is often more expensive to unwind than to redo cleanly.
Why an Outside Assessment Matters Here
Internal teams closest to a struggling project often have the hardest time making this call objectively — sunk cost, personal investment in decisions already made, and simple fatigue all push toward either extreme, minimizing real problems or catastrophizing fixable ones. A genuine outside assessment, looking specifically at the data model, the configuration logic, and the actual gap between current state and requirements, produces a far more reliable answer than an internal gut check under pressure.
What Stabilization Actually Involves
When stabilization is the right call, it typically means a focused, prioritized plan addressing the specific broken pieces — often data cleanup, targeted reconfiguration, and a realistic revised timeline — rather than either abandoning the work or plowing forward on the original plan unchanged. It's neither "keep going exactly as before" nor "start over." It's a deliberate correction informed by a clear-eyed look at what's actually salvageable.
Where to Start
If your project is showing real strain — missed dates, eroding trust, mounting frustration — the first step isn't deciding whether to restart or push forward. It's getting an honest, specific assessment of which category your project actually falls into, from someone without a stake in how you got here.