Most Dynamics 365 projects that stall do not fail in a single moment. The go-live date moves once, then again. Budget conversations get uncomfortable. Testing turns up the same defects twice. The project team is still working hard, but nobody can say with confidence when the system will be ready. If that sounds familiar, the project can usually be recovered, but not by doing more of the same.
This is the approach we use when we are asked to step into a stalled Business Central or Finance and Supply Chain Management implementation. It applies whether you are still with your original partner, between partners, or running the project internally.
Recognize the warning signs early
A project needs an outside look when several of these are true:
- The go-live date has moved more than once without a clear reason.
- Requirements are still being discussed while build is supposedly finished.
- User acceptance testing keeps finding issues in areas already marked complete.
- Data migration has not been run end to end with real data.
- Key users have stopped attending sessions, or have built their own workarounds.
- The steering committee hears status reports that are green, but the team on the ground says otherwise.
None of these is unusual on its own. Together they mean the project plan no longer describes reality.
Step 1: Pause and establish the facts
The first two weeks of a recovery are about evidence, not opinions. We review:
- Scope: the signed requirements, the change requests since, and what users now expect.
- Solution: configuration, customizations and extensions actually built, and their quality.
- Data: the migration approach, the number of trial loads, and reconciliation results.
- Testing: test scripts, defect logs and which processes have truly passed end to end.
- People: who makes decisions, who has left, and where knowledge is concentrated in one person.
- Contracts and licences: what has been paid for, what remains, and whether the licence mix matches the design.
The output is a short, plain report: what works, what does not, what is missing, and what it will realistically take to finish.
Step 2: Reset scope to what go-live really needs
Stalled projects often carry years of wishes. Recovery means separating three lists:
- Must have for go-live: processes the business cannot run without on day one.
- Can follow shortly after: valuable improvements that can be delivered in a planned phase two.
- Not needed: requests that no longer make sense, or that standard Dynamics already handles differently.
Every custom requirement is challenged against standard functionality. Fewer customizations mean faster testing now and easier updates later, especially on Business Central and Finance and Supply Chain Management where Microsoft releases updates on a regular cadence.
Step 3: Fix the foundations before adding features
Recovery work goes in a specific order:
- Stabilize the environments, so test and production configurations do not drift apart.
- Correct core setup issues such as the chart of accounts, dimensions, posting setup and tax.
- Repair or replace customizations that are unstable or unnecessary.
- Get a full data migration running and reconciling, because nothing else can be tested properly without it.
Only once these are solid does it make sense to resume new build.
Step 4: Rebuild trust with a plan people can check
A recovery plan must be specific enough that the business can tell whether it is on track. That means:
- Short, fixed delivery cycles with visible outputs, typically every two weeks.
- Entry and exit criteria for each test cycle, agreed with the process owners.
- A single defect list with clear priorities and owners.
- A go-live readiness checklist covering data, training, cutover and support, reviewed weekly.
Status reporting changes from percent complete to what users can actually do in the system today.
Step 5: Go live deliberately, then support hard
A recovered project should go live with a rehearsed cutover, a reconciled data load and named people supporting each area for the first weeks. Plan for intensive support through the first month-end close, because that is where hidden setup issues appear. After that, move to a normal support rhythm and start phase two.
What recovery is not
Recovery is not a blame exercise, and it is rarely a full restart. In most projects a significant part of the configuration and data work is reusable. The goal is to keep what is sound, fix what is not, and give the business a date it can believe.
Talk to someone who has done it
Our team has recovered 8 stalled ERP implementations and taken 16 projects to go-live. If your Dynamics 365 project has lost momentum, read how our project recovery service works, or book a short call to talk through where things stand. A 30-minute conversation is usually enough to tell whether an assessment is worthwhile.