Finance and Operations or Business Central.
Microsoft sells two ERPs under the Dynamics 365 name, and they differ by an order of magnitude in cost and implementation effort. This guide covers what each is, the factors that actually decide the choice, and the wrong reasons that lead organisations astray.
Two products, one brand
Business Central descends from NAV; Finance and Operations descends from AX. They share a brand, a cloud and an interface family, and almost nothing else that matters to the decision: different codebases, different data models, different implementation economics, and, importantly, no upgrade path between them. An organisation that outgrows Business Central reimplements; it does not upgrade. That fact alone justifies making the choice carefully, because the cheap correction does not exist.
What each one is
Business Central is a complete mid-market ERP: finance, inventory, purchasing, sales, projects and light manufacturing in one product, implementable in months, extended through AppSource rather than heavy custom development. Its sweet spot is organisations with conventional processes who want enterprise discipline without enterprise overhead, and its economics reflect that: licensing runs at a fraction of F&O's per user, and a capable implementation partner can have a single entity live inside a quarter or two.
Finance and Operations is an enterprise ERP: deep multi-entity financials and consolidation, advanced supply chain and warehousing, discrete and process manufacturing, and the configurability to model genuinely complex operations. That depth is why multinationals run it, and why implementations are measured in quarters to years, with programme disciplines, environment strategy, data migration rehearsal, One Version regression machinery, that Business Central projects rarely need at the same intensity.
The factors that actually decide it
Process complexity, not headcount. A 900-person professional services firm with simple operations fits Business Central comfortably; a 150-person process manufacturer with batch traceability, quality management and complex costing can exhaust it. Count the complexity of what the business does, not the people doing it.
Legal entities and consolidation. Business Central handles multiple companies and intercompany transactions adequately at moderate scale. Many entities, many currencies, statutory consolidation across jurisdictions and shared services centres are F&O territory, and forcing them into BC produces the spreadsheet layer the ERP was meant to remove.
Manufacturing and warehouse depth. Light assembly and standard warehousing sit inside BC's range. Advanced warehousing, wave planning, detailed shop floor control and process manufacturing are where F&O's depth stops being optional.
Transaction volume and localisation breadth round out the list: sustained high-volume order processing favours F&O's architecture, and operating across many countries favours its localisation coverage, though BC's country coverage is broader than its reputation suggests and should be checked against your actual footprint rather than assumed either way.
The shape of the costs
The licensing gap is public and substantial: F&O runs at several times BC's per-user rate, before the operations users, device licences and attach licences that enterprise deployments accumulate. The implementation gap is larger still. A BC project is typically a low-to-mid six-figure engagement; an F&O programme starts around the high six figures and rises with entities, integrations and geography. Ongoing costs follow the same ratio, because F&O estates carry more environments, more regression testing and more specialised support. None of this makes F&O expensive in any absolute sense; it makes it expensive for organisations that did not need it, which is the scenario the decision process exists to prevent.
The wrong reasons, named
Three bad reasons account for most regretted choices. Choosing F&O for prestige, because the board has heard of the enterprise product, buys years of implementation and running cost for depth the business never uses. Choosing BC purely on price, against the advice of a fit-gap that showed manufacturing or consolidation gaps, defers the cost into a reimplementation three years later, plus the workaround years in between. And "we will start on BC and upgrade later" plans for an upgrade path that does not exist; if the three-year picture clearly needs F&O, the honest comparison is BC-then-reimplement against F&O-now, with real numbers on both.
Where you are coming from matters
Migration source shapes the natural landing point. NAV and GP estates map naturally onto Business Central, and Microsoft's tooling and partner ecosystem are built around that path. AX estates map onto Finance and Operations, with the code and data upgrade route covered in our AX 2012 migration guide. Neither mapping is compulsory, and a heavily customised AX estate whose business has simplified is sometimes better served by BC than by carrying enterprise machinery forward. The source system is evidence about your complexity, not a verdict.
How to decide in practice
The reliable process is short: an inventory of your processes with the genuinely complex ones flagged, a fit-gap of those flagged processes against both products run by someone who has implemented both, reference conversations with organisations of your shape on each product, and a five-year cost model per option that includes the implementation, the licensing and the support reality. That work takes a few weeks, and it is cheaper than either mistake by a couple of orders of magnitude. Our Dynamics 365 practice implements both products, which is the position from which the advice stays honest.
Tell us what the business runs on.
An ERP selection in progress, a legacy system with a deadline, or a fit-gap you want run by people who implement both products. A consultant replies within one business day.