Most Business Central projects don’t fail because of the software. They fail because of decisions made in the first few weeks before a single invoice is posted. Here are the Eight Mistakes that show up again and again, and what to do instead.
Skipping Proper Process Discovery
Teams rush into configuration because “we already know how BC works.” But every business has quirks. How they handle returns, how they cost inventory, how approvals actually happen (not how the org chart says they happen). Skip discovery, and you end up reconfiguring the same module three times during UAT.
Do this Instead: Spend real time mapping current processes before touching the system. Ask “why” twice on anything that seems odd there’s usually a reason.
Trying to Replicate the Old System
This is the opposite problem. If the client says, “just make it work like our old ERP,” you’ll end up with a customized mess that fights BC’s natural design at every step, and every future upgrade becomes painful.
Do this Instead: Use the old system as a reference for requirements, not a blueprint for configuration. Ask what the old system was actually trying to achieve, then solve it the BC way.
Under-Scoping Data Migration
Data migration is usually the most underestimated line item in the whole project. Master data is messy, historical data is inconsistent, and “we’ll just export from the old system” almost never works cleanly.
Do this Instead: Start data cleansing early ideally before the project even kicks off. Decide explicitly what history actually needs to migrate versus what can stay archived in the old system for reference.
Over Customizations
Every custom AL extension is a future upgrade cost, a future testing burden, and a future point of failure. Yet teams reach for customization before checking whether BC already does what they need, just configured differently.
Do this Instead: Default to standard functionality first. If a customization is genuinely needed, build it as a clean extension. Never modify base objects so future upgrades stay smooth.
Ignoring the Finance-to-Operations Connection
BC’s real strength is how tightly finance connects to inventory, manufacturing, and sales. Projects that treat finance as “just the GL setup” and operations as a separate workstream end up with numbers that don’t reconcile later.
Do this Instead: Get finance and operations stakeholders in the same room from day one. Posting setup, inventory valuation, and cost flow decisions affect both sides.
Weak Testing Before Go-Live
Real testing means running full business scenarios end-to-end like order to cash, procure to pay, full manufacturing cycles with real volumes, not just sample records.
Do this Instead: Build test scripts around actual business scenarios, not just “does the button work.” Include edge cases: partial shipments, returns, multi-currency, period-end close.
After Go-Live
Go-Live isn’t the finish line. It’s the start of the part where the system actually gets used under real pressure. Projects that treat go-live as “done” leave clients stuck when the first real problem hits.
Do this Instead: Define a hypercare period with clear ownership: who fixes what, how fast, and for how long after go-live. Don’t let support just quietly dissolve.
Underestimating Change Management
People don’t resist new software, they resist having their job change without being asked. Even a technically perfect implementation can fail if the human side is ignored.
Do this Instead: Communicate early and often about “why” the change is happening, not just “what’s” changing. Involve end users in decisions that affect their daily work, even in small ways. It builds ownership instead of resistance.