A Business Central implementation follows a predictable sequence, but the effort in each step surprises many first-time buyers. This article walks through the phases we use, what should happen in each, and where projects tend to go wrong.
Phase 1: Discovery and scoping
The aim is to understand how the business works today and what it needs from the system. That means workshops with the people who do the work: finance, sales, purchasing, warehouse, production. Requirements are captured as processes and outcomes ("invoice within a day of shipment") rather than as feature requests.
Where it goes wrong: only the project sponsor is interviewed, and the real workarounds never surface until testing.
Phase 2: Fit-gap analysis
Each requirement is compared with standard Business Central and categorized: covered by standard functionality, covered by configuration, needs an extension, needs an integration, or should be handled by changing the process. This document drives scope, budget and risk. It is also where you decide what not to customize.
Where it goes wrong: every gap is assumed to need code. Many are solved by setup, a Power Automate flow or a small process change.
Phase 3: Solution design
The design covers the company structure, chart of accounts, dimensions, posting groups, number series, approval flows, roles and permissions, along with the technical design for extensions, integrations and reports. Dimension and chart-of-accounts design is worth extra time, because it shapes every report the business will produce.
Phase 4: Configuration
The system is set up in a sandbox, in iterations, and reviewed with key users. Early demonstrations use the customer's own scenarios and data, which is far more convincing and revealing than a generic demo.
Phase 5: Data migration
Master data (customers, vendors, items, bank accounts) and opening balances are extracted, cleaned, mapped and loaded. The most reliable approach is repeatable migration runs, each reconciled against the source: trial balance to trial balance, open receivables and payables to the aged ledgers, inventory quantities and values to the stock report. Expect several rehearsals before the final one.
Where it goes wrong: data cleaning is left to the last two weeks, and duplicates, missing tax details and inconsistent units of measure appear at go-live.
Phase 6: Development and integration
Extensions, reports and integrations are built against the agreed design. Good practice means source control, code review, code analyzers and automated tests for calculation-heavy logic. Integrations are tested for failure cases as well as the happy path. See our development approach and integration services.
Phase 7: Testing and user acceptance
System testing verifies that each process works end to end, from order to cash and from purchase to pay. User acceptance testing has the actual users run realistic scenarios, including month-end and exception cases. Defects are triaged, and go-live criteria are agreed in advance.
Phase 8: Training
Role-based training should use the configured system and the company's own data. Super-users are trained first and then help their teams. Short reference guides written for your processes are more useful than generic manuals.
Phase 9: Cutover and go-live
A cutover plan lists every step, owner and time: freeze the old system, extract final balances, load, reconcile, run smoke tests, open the system to users. A rollback decision point is defined before the weekend starts, not during it.
Phase 10: Hypercare and ongoing support
The first weeks and the first period-end close are when unexpected issues appear. A defined stabilization period with fast access to the implementation team pays for itself. After that, an ongoing support arrangement keeps the system aligned with the business as it changes.
How long does it take?
It depends on the number of legal entities, modules in scope, integrations, data volume and how many gaps need development. A single-entity finance and trade implementation is a different project from a multi-site manufacturing rollout, and any reliable estimate needs a discovery conversation first. Costs follow the same logic, with Microsoft licensing separate from implementation services.
What makes projects succeed
- An empowered internal project owner who can make process decisions.
- Key users who are given real time to participate.
- A fit-gap discipline that keeps customization small.
- Data migration treated as a project of its own.
- Testing with realistic scenarios and honest go-live criteria.
To see how we structure this work, visit our Business Central implementation page, or read the broader Business Central guide. Learners who want to understand these phases from the consultant's side can explore our functional training.
Key takeaways
- A fit-gap analysis early in the project prevents unnecessary customization.
- Data migration should be rehearsed several times before go-live.
- User acceptance testing needs real scenarios, not feature demos.
- Support after go-live is part of the project, not an afterthought.
Central Era TechnologiesWritten by the consultants and developers at Central Era Technologies, who work with Business Central, Dynamics 365 Finance and Operations, Power Platform and Azure. To credit a named author, add one here.