10 Red Flags Your Business Central Implementation Will Fail

Failed ERP implementations rarely fail suddenly. The warning signs appear weeks or months before the project collapses — they are just easy to miss when you are inside the project and busy. This guide is what I look for when I am called in to assess whether a Business Central implementation is on track, in trouble, or already lost. If you recognise 3 or more of these flags in your current project, you are at risk. The earlier you act, the more salvageable the project is.

Red Flag 1 — The Partner Says "Yes" to Everything

A competent BC partner will tell you when a requirement is a bad idea, when a customisation is unnecessary, or when a timeline is unrealistic. If your partner has agreed to every requirement, every change, and every deadline without pushback, they are either inexperienced or they are deferring difficult conversations to a later stage of the project — when changing course costs significantly more.

Red Flag 2 — No Named Functional Lead From Your Side

BC implementations require a named business owner — someone from your organisation who is accountable for the functional decisions throughout the project. Not the IT director, not a steering committee. A specific person who understands the operations and has the authority to make decisions when the partner asks "should the system do A or B?"

When this role is unfilled, decisions get made by the partner based on best guesses or by whoever happens to be in the room. Both are how systems end up not fitting how the business actually works.

Red Flag 3 — Process Documentation Is "We'll Do It Later"

If your project plan does not include detailed business process mapping before configuration begins, the configuration will be based on assumptions. Those assumptions are wrong often enough that the cost of fixing them post-UAT exceeds the cost of mapping properly upfront.

Red Flag 4 — Heavy Customisation Discussed Before Standard BC Is Demonstrated

When the conversation in early project meetings is dominated by customisations and AL extensions, before the team has seen what standard BC actually does, you are heading for an over-customised system. Many capabilities that NAV required custom code for are now native in BC. A good partner shows the standard first and only customises where standard genuinely does not fit.

Over-customised BC systems are more expensive to build, more expensive to upgrade, and more fragile. Every customisation is technical debt that someone has to maintain — and that someone is paid by you.

Red Flag 5 — No Defined Data Migration Strategy by Week 3

Data migration is the #1 cause of go-live delays. If your project is past week 3 and there is still no documented strategy for migrating master data, open transactions, and historical data, the migration will be rushed, untested, and risky.

Red Flag 6 — UAT Is Compressed or Performed by the Wrong People

UAT compressed from 3 weeks to 1 week is the most common pre-go-live cost-cutting move, and it is one of the most damaging. The reasoning ("we are behind schedule, UAT can be shorter") guarantees that real-world issues will be found by end users at go-live instead of by testers in advance.

Equally damaging: UAT performed by IT staff or "super users" instead of the actual people who will use BC every day. Super users know what the system is supposed to do; they are less likely to find the edge cases that only emerge when real workflows hit unusual scenarios.

Red Flag 7 — Training Plan Is "We'll Cover It in Two Days Before Go-Live"

ERP user adoption is determined by training quality, not training quantity — but two days of cramming before go-live produces neither. Users leave the sessions overwhelmed, forget half of what they learned by the time they need it, and develop workarounds because the proper process feels unfamiliar.

Red Flag 8 — Steering Meetings Are Cancelled or Skipped

Steering committee meetings are the project's circuit breaker. They are where risks get escalated, scope conflicts get resolved, and resource issues get addressed. When steering meetings start getting cancelled because "there is nothing new to report" or "everyone is busy this week," the project loses its escalation path. Issues that should be visible to senior stakeholders get buried at the working level until they explode.

Healthy projects: weekly working meetings + biweekly steering committee, both consistently held with documented decisions. Unhealthy projects: working meetings only, with steering committee invoked only when things are already on fire.

Red Flag 9 — The Partner Team Keeps Changing

BC implementations require continuity. The consultant who ran the requirements workshops in week 2 should still be on the project at UAT in week 16. When you notice that the partner team has rotated — the original lead is now on another project, a new functional consultant arrives mid-stream, the developer who built your customisations has been "reallocated" — institutional knowledge of your project is being lost.

The replacements have to learn what was already discussed, re-read the documentation (if it exists), and rebuild context. This loss is invisible in status reports but emerges as quality issues, missed requirements, and rework later in the project.

Red Flag 10 — There Is No Post-Go-Live Plan

When you ask "what does support look like for the first 8 weeks after go-live?" and the answer is "we'll be available if you need us" or "you can log tickets via our portal," there is no post-go-live plan. There is just hope that nothing will go wrong.

Hypercare — a structured period of intensive support immediately after go-live — should be a defined deliverable with named resources, response time commitments, and a planned transition to steady-state support. Without it, the first major issue post-go-live becomes a crisis. With it, the same issue is just a Tuesday morning ticket.

What to Do When You See These Flags

The instinct when a project is in trouble is to push harder — more hours, more meetings, more pressure. This rarely works. The flags above all share a common cause: the project plan does not match the project's actual complexity. Pushing harder on a flawed plan produces a flawed system faster, not a better outcome.

The action that works is honest assessment and replanning. Sometimes that means the partner stays and the project is restructured. Sometimes it means a change of partner. Either way, the conversation cannot be avoided — and the cost of avoiding it goes up every week the flags remain.