Gartner told analysts in November 2025 that 70 percent of ERP initiatives fail to fully meet their original business case goals, and 25 percent fail outright. Dynamics 365 is not exempt from that pattern. Whether you are still weighing the ERP implementation risk of a new project or six months into a rollout that no longer feels on track, the Dynamics 365 implementation red flags below tend to show up early and get explained away for months before anyone calls the project "at risk." This piece walks through 12 concrete warning signs, explains what each one usually means underneath the surface, and gives you a way to score your own project so you know whether it is time to escalate.

What causes most Dynamics 365 implementations to struggle?

The failure rate is not unique to Dynamics 365, and it is not mysterious. Panorama Consulting Group's 2025 ERP Report found that more than a quarter of organizations exceeded their project budgets, most often because additional technology needs surfaced mid-project rather than during planning.

Godlan's 2026 analysis of more than 2,400 ERP implementations found that inadequate change management, poor data migration, and inexperienced implementation teams together account for more than 75 percent of all failures. None of those three causes are about the software itself.

One cause that is more specific to Dynamics 365. It is a suite, not a single application: Finance and Operations or Business Central on one side, Sales, Customer Service, and Field Service on the other, all built to share data through Dataverse. A common pattern behind a failed Dynamics 365 project is treating it like a single-module ERP deployment, getting the finance side configured well, and leaving the customer-facing and field service modules disconnected or out of scope entirely. That gap does not always show up in a status report. It shows up operationally, months later, as double data entry and numbers that do not reconcile between departments.

The 12 warning signs

1. The go-live date has already moved more than once. One slipped date is normal; complex data migrations and integration testing regularly surface issues that push a deadline by a few weeks. Two slips form a pattern worth asking about. Three or more usually means the team is re-baselining the plan instead of re-planning it, resetting the date without addressing why the last estimate was wrong. Ask your partner or internal project manager to name the specific tasks that caused each delay; a vague answer is the real warning sign, not the date itself.

2. Nobody can show you a working system. Demos are still slide decks, or the environment you're shown is a vanilla, unconfigured instance rather than your own chart of accounts, item master, or service territories. If you are six months into a Finance and Operations or Business Central project and still cannot see your own data moving through a configured process, the project is further behind than status reports suggest. Ask to see one end-to-end process, quote to cash or procure to pay, running against a copy of your real data.

3. Requirements keep getting pushed into phase two. A healthy backlog gets triaged, with some items shipping now and some later by agreement. A troubled backlog grows a phase two list that quietly absorbs the hardest items, intercompany transactions, landed cost, technician scheduling, the reasons you bought Dynamics 365 in the first place. Check what is actually sitting in phase two against what was in your original business case, and ask who decided it could wait.

4. Your own staff are doing the implementation partner's job. Controllers writing functional specs, IT leads debugging integrations, operations managers building test scripts the partner should own. When this happens, you are paying twice, once in consulting fees and once in the hours your own people are pulled off their regular work. Track how many hours your internal staff spend each week on deliverables the partner is contracted to own, and raise it at your next steering committee meeting if the number is climbing.

5. You have lost track of who is actually running the project. Partner-side staff changes happen on any implementation that runs a year or more, but two or three different solution architects or project managers means institutional knowledge of your business is leaving with each one. Every replacement needs weeks to relearn your approval workflows and your exceptions. Ask directly how many people from the original proposal are still assigned; turnover on the partner side predicts delays more reliably than almost any other single factor.

6. Every open question gets answered with custom code. Finance and Operations and Business Central both cover a wide range of standard functionality. A partner who reaches for a custom extension before exhausting standard configuration is often covering a gap in their own product knowledge rather than solving a genuine business requirement. Every unnecessary customization becomes a cost carried at every future update, so for each proposed custom build, ask what standard configuration was tried first and why it did not work.

7. Sales, Customer Service, Field Service, and Finance are still not talking to each other. Dynamics 365 is sold as a connected suite, but plenty of implementations only touch one corner of it, usually Finance and Operations or Business Central, and leave Sales, Customer Service, and Field Service running as they always have, whether that is a separate CRM, a spreadsheet, or a legacy scheduling tool. When that happens, a signed quote does not automatically become an order in Finance, a technician still logs hours on paper before someone re-enters them, and customer history lives in three places that disagree. The tell is usually operational, not technical: double data entry, manual exports between systems, or a reporting team spending more time reconciling numbers than analyzing them. If your project plan never mentions Dataverse or a shared data model across modules, ask why.

8. Change orders are becoming the norm rather than the exception. Some scope change is expected on a project of this size, but weekly change orders three or four months in, for items that feel like they should have been caught during discovery, point to a scope that was thinner than it should have been going in. Track what share of your current budget change orders represent; anything above 10 to 15 percent of the original contract value is generally considered risk territory. Separate legitimate new requirements from items discovery simply missed, and ask your partner to account for the difference.

9. Testing time keeps getting cut to protect the date. When a project falls behind, testing is often the first phase to shrink, because it is the easiest to compress without an immediate visible consequence. The consequence arrives later, when defects that should have been caught in a test environment show up in production instead during the first weeks after go-live. A proposal to cut user acceptance testing from four weeks to two is a decision for your executive sponsor, not your project manager, because it is a risk tradeoff rather than a scheduling one.

10. Employees still call it "IT's project." A Dynamics 365 rollout succeeds or fails on adoption, and adoption depends on whether the people using the system daily feel like they helped shape it. If your finance team, dispatchers, or account managers still describe the system as something being done to them, expect a rough first quarter after go-live regardless of how clean the configuration is. Low attendance at training, minimal feedback during user acceptance testing, and a steady stream of workaround requests are symptoms of the same root problem, and one that is far harder to fix after go-live than before it.

11. The budget conversation has changed tone. Early on, budget conversations are usually about adding scope, a new integration, an extra report, a nice-to-have workflow. Later, if the tone shifts to what it will cost to finish what was already agreed to, the original estimate was wrong somewhere, and someone needs to own that gap. This shift is easy to miss because it happens gradually. Look back at your last three budget updates and ask whether they funded growth or funded recovery.

12. Support responsiveness drops as go-live approaches, or right after it. The weeks before and immediately after go-live are when your team needs the most partner attention, not the least, yet this is often when response times slip from hours to days as the partner's best people rotate to the next engagement. If ticket response times slow right when your organization is under the most stress, that is rarely a coincidence; it usually means stabilization was under-resourced to protect someone else's margin. Define support service levels in writing before go-live and track actual performance against them from day one.

How to score your own project

Read through the 12 signs above and give your project one point for every sign that is currently true. Most projects will recognize at least one or two along the way, and that alone is not cause for alarm. The total tells you how urgently to act.

0 to 2: normal friction. Keep monitoring; no need to escalate yet.

3 to 5: worth a closer look. Raise it at your next steering committee meeting and ask for the specifics behind each sign you checked.

6 to 8: the project is genuinely at risk of becoming a stalled ERP implementation. An independent, structured review is worth the time and cost before more budget goes in.

9 to 12: this needs an executive-level decision now, not a status update. Continuing without a hard look at scope, team, and plan is usually the more expensive option, not the safer one.

What to do if you score 6 or higher

If you are still evaluating a partner, a score this high in your own upfront thinking, an unrealistic timeline, no named resources, and vague data migration scope are reason enough to slow down and ask harder questions before signing. Request a detailed project schedule with named individuals, references from organizations your size and industry, and a data migration plan with defined success criteria. A partner who resists these requests at the proposal stage will resist them once the contract is signed.

If you are already mid-implementation, resist the instinct to assume a fix means starting over. In most rescue situations, 60 to 80 percent of prior work, licensing, environments, and much of the configuration is salvageable. Start with an independent, fixed-scope assessment of the solution design, data migration approach, and project governance, done by someone other than whoever built it, so you get a candid picture rather than a defence of past decisions. That assessment should tell you what is salvageable, what needs rework, and a realistic cost and timeline to finish- information you can act on with your current partner or a new one.

Either way, avoid the sunk cost trap. Money already spent is gone regardless of what you decide next. The only question that matters is which path costs less from here: continuing to fund a project with no credible finish line, or pausing now to reset scope, resourcing, and plan before the write-off gets bigger.