Best practices for a complex Business Central implementation that do not come from a handbook

The best practices that actually work for a complex Business Central implementation are not a checklist but an order: foundation first, then standard before custom, then a pilot instead of a big bang. Reverse that order and you are building speed on sand. Before any configuration there are exactly three questions: is the master data sound, are the core processes settled, and is it named who decides bindingly when goals conflict. Without those three answers, every implementation week turns into a week of debate. The reason is mechanical: an implementation consists mostly of decisions, not of configuration. If the basis for deciding is missing, decisions get made in a workshop under time pressure, and then the loudest voice wins rather than the best reasoning. Those three questions can be answered in advance, in weeks rather than months. That is precisely why this groundwork is not a delay but the cheapest part of the project.

Why does the foundation come first?

Before any configuration there are exactly three questions: is the master data solid, are the core processes clarified, and is it named who decides conflicts of goals with authority. Without those three answers, every implementation week turns into a week of debate.

The reason is mechanical. An implementation consists largely of decisions, not of configuration. When the basis for a decision is missing, it gets made in a workshop under time pressure, and then the loudest voice wins instead of the best reasoning.

The three questions can be answered up front, and in weeks rather than months. Master data is measurable, processes can be captured in a preliminary project, and decision ownership is a staffing decision, not an analysis. That is exactly why this preparatory work is the cheapest phase of the entire project, measured against what it prevents later.

Why standard before custom, and pilot instead of big bang?

The most expensive mistake in complex projects is to rebuild grown special paths one to one. A senior approach uses Business Central as home, checks every customisation request against the standard and allows extensions only where you truly differentiate.

Source: Microsoft Learn: Development in AL

And instead of a big bang, a representative section goes live first, on real processes and real data. What surfaces there surfaces in a controlled way, not on go-live day across all areas at once.

The pilot has a second, underestimated benefit: it proves to the business that the system holds. Trust grows from real documents and a real month-end close, not from a presentation. Whoever drops the pilot to save time does not shift the effort, only the point at which the problems become visible, and to the worst possible one.

Why does it need governance from day one?

These artefacts sound unspectacular and are the difference between staying in control and lagging behind:

• A decision log and a prioritised backlog.
• Acceptance criteria per module.
• A data owner per master-data domain.
• Testing and data migration early and in real test runs, not in the last project week.

Order before speed: a realistic frame that respects the foundation reaches a solid go-live faster than an ambitious plan that skips it. The last point on the list is the one most often violated: data migration and testing regularly drift into the final weeks, although both produce findings that affect the scope. If you are facing a complex implementation and want to secure the order, we go through your foundation in a first conversation. Control stays on your side throughout, with Business Central as home.