A Dynamics 365 implementation rarely fails loudly. It slips. The go-live date moves for the third time, the customisations nobody quite signed off keep multiplying, the finance team is already rebuilding reports in Excel, and the partner keeps billing while working functionality stays stubbornly out of reach. By the time it reaches the board, the question has changed from "will this go well" to "how much more will it cost us to stop the damage".
I have been called in at exactly that point more than once, including to recover a failed multi-million-pound ERP programme and return it to delivery inside four months. The reassuring truth for any board reading this is that a stalled Dynamics 365 programme is almost always recoverable, and you rarely need to start again. What you need is a disciplined reset. This is the 90-day plan I use to deliver one.
Why Dynamics 365 implementations stall
Dynamics 365 is a capable, proven platform, whether you are running Finance and Operations across a complex group or Business Central in a growing mid-market business. It very rarely fails because of the software. It fails because of how the programme was scoped, governed and run.
The warning signs are consistent, and if you recognise three or more, you have a programme in trouble:
- The go-live date has moved more than twice, and nobody can tell you with confidence what the next one depends on.
- Customisation has run away. Instead of adopting standard Dynamics processes, the system is being bent to mirror exactly how you work today, adding cost, risk and a painful upgrade path.
- Scope has quietly expanded from a defined ERP rollout into a business-wide transformation, without the budget or governance to match.
- Your implementation partner is billing steadily, but progress is measured in activity rather than working, tested functionality.
- Key business users have disengaged, and testing is being done by the project team instead of the people who will actually use the system.
- Data migration is treated as a technical task for the end, rather than the highest-risk item in the whole programme.
None of these is fatal alone. Together they compound, and the programme loses the one thing it cannot afford to lose: the confidence of the people paying for it.
Days 1 to 30: Stabilise and diagnose
You cannot fix what you have not honestly measured. The first month is not about configuration or code. It is about establishing the truth and stopping the programme getting worse.
I start with a rapid, independent assessment of where the implementation actually stands against where it was meant to be: configuration complete versus planned, the scale of customisation, data readiness, integration status, testing coverage, and the real gap between the two. This is deliberately uncomfortable, because most troubled programmes are carrying an optimistic status report that no longer reflects reality, and the reset cannot begin until that gap is on the table.
In parallel I stabilise governance: a single accountable owner, a decision-making cadence that actually makes decisions, and a re-baselined view of scope, cost and risk the board can trust. Where the partner relationship has broken down, this is the month to decide whether it can be repaired or needs to change, which I return to below.
By day 30 you should have an honest baseline, a governance structure that works, and a clear view of whether the programme needs re-planning, re-staffing, or both.
Days 31 to 60: Re-plan and rebuild
With the truth established, the second month rebuilds the plan and the momentum. The temptation here is to rush back to a go-live date. Resist it.
Re-anchor the implementation to a clear target operating model: what finance, supply chain and operations should actually look like after go-live. Then make the single most important decision in any Dynamics recovery, which is to stop over-customising. Adopt standard Dynamics 365 functionality wherever it is good enough, and reserve customisation for genuine competitive differentiators. Every bespoke extension you remove is cost, risk and future upgrade pain you remove with it.
Re-scope ruthlessly: separate what must be live on day one from what can follow in a fast second phase. A leaner, credible first release beats a comprehensive one that never ships. And bring data migration forward as a first-class workstream with its own owner, because it is almost always the item that sinks go-live. Cleanse, map and run trial migrations early, so the data becomes a known quantity rather than a last-minute gamble.
Finally, re-engage the business. The people who will live in Dynamics every day must be back inside the programme, testing against real scenarios and signing off what good looks like. A system the business has not tested is not ready, however green the plan looks.
Days 61 to 90: Deliver, embed and hand over
The final month is controlled delivery, and making the recovery stick. By now the plan is credible, the data is trusted, and the business is engaged. The job is to bring it home without reintroducing the risks you have just removed.
That means disciplined user acceptance testing led by the business, a go-live decision based on clear, agreed criteria rather than a date in a diary, and a cutover plan with a genuine fallback. It means hypercare: intensive support in the days and weeks after go-live, when issues surface and confidence is won or lost. And it means capturing the second-phase backlog so deferred scope is a plan, not a broken promise.
Just as importantly, it means handover. A rescue that depends forever on the person who ran it has not really succeeded. I make a point of leaving a stable system, a capable internal team, and governance that will hold, so the business owns its Dynamics platform rather than renting the confidence to run it.
When to change your Dynamics 365 partner
Boards often assume a failing implementation means firing the partner. Sometimes it does. More often, the partner is competent but was set up to fail by unclear scope, weak governance and an absent business.
The honest test is this: is the partner delivering poor-quality work, or delivering competent work against a broken brief? If it is the former, and trust has gone, change is usually the right and faster route. If it is the latter, replacing them resets the clock and loses hard-won product knowledge for no real gain. Part of the value of an independent recovery lead is making that call dispassionately, in your interest rather than anyone else's.
Frequently asked questions
Why do Dynamics 365 implementations fail?
Almost never because of the software. They fail through unclear scope, runaway customisation, weak governance and data migration left too late. Adopt standard functionality, govern tightly and treat data as the priority, and the platform performs as intended.
Can a failing Dynamics 365 project be recovered?
In the large majority of cases, yes, and without starting again. A disciplined 90-day reset, an honest baseline, a re-planned scope anchored to a clear operating model, reduced customisation and data brought forward, is usually enough to return a stalled programme to delivery.
How long does a Dynamics 365 rescue take?
Stabilisation and re-planning can be achieved in the first 30 to 60 days, with a controlled go-live typically inside 90. Complex, multi-entity Finance and Operations environments may need a longer second phase, but the recovery itself is fast because it is about discipline, not rebuilding.
Is the approach different for Business Central and Finance and Operations?
The principles are identical. Finance and Operations programmes tend to carry more integration and customisation risk, so scope discipline matters even more, while Business Central recoveries are usually faster, but in both cases the failure modes and the fix are the same.
Do I need to replace my implementation partner?
Not necessarily. If the partner is competent but was handed a broken brief, replacing them resets the clock for no gain. If quality is poor and trust has gone, change is the faster route. The decision should be made independently, in the business's interest.
Recover the programme, not just the system
A troubled Dynamics 365 implementation is a governance and leadership problem wearing a technology costume. Solve it in that order, stabilise, re-plan, deliver, and the platform does exactly what you bought it for.
If your Dynamics 365 programme has stalled and you need an experienced, independent pair of hands to get it back on track, book a confidential conversation. I have recovered failing ERP programmes across Dynamics 365, SAP S/4HANA, NetSuite and Oracle, including for PE-backed businesses where time to value is everything. For the wider picture of why these programmes fail and how recovery works, see my guide to why ERP implementations fail and how to recover.