Business Central vs Finance and Operations

The "Business Central or Finance and Operations" question comes up in almost every Microsoft ERP conversation, and the honest answer is that they solve different problems for different organisations. This guide walks the criteria that actually decide, in the shape they surface in real projects.

Business Central (BC) is the SaaS ERP for small and mid-sized businesses — descendant of Dynamics NAV. Dynamics 365 Finance and Supply Chain Management (F&O) is the enterprise ERP — descendant of Dynamics AX. Both are Microsoft products, both are Dynamics 365, both run on Azure. Everything else about them is different: architecture, extensibility model, licensing, and the shape of the implementation.

The rough size line

For fast triage, the rules of thumb: below roughly 100 concurrent ERP users and around €200M revenue, Business Central is almost always the right choice. Above roughly 500 users and €500M+ revenue, F&O is almost always right. In between is the interesting zone, and headcount alone does not decide.

The deciding factors above the numbers are the shape of the operations, not the raw scale.

When Business Central is right

Business Central fits when the business:

• Runs in a small number of legal entities — one, maybe a handful.
• Has straightforward accounting: one chart of accounts per country, one currency dominant, standard VAT / sales tax with a country localisation available.
• Has moderate operational complexity: multi-location warehousing, light assembly or trade goods, jobs and project accounting for services.
• Wants a fast time-to-value: a 3–6 month implementation is the expected shape.
• Has a partner-led model rather than an internal ERP platform team.

A business at 300 users running BC well is normal. A business at 800 users running BC well exists but is less common — usually because the operational complexity is genuinely simple even at scale.

The extensibility model (AL extensions, monthly updates, non-breaking upgrades) is the platform's biggest structural advantage. Once configured, BC keeps updating itself and the extensions come along for the ride. The trade-off is a lower ceiling on customisation depth.

When Finance and Operations is right

F&O fits when the business has one or more of:

Multi-entity complexity. More than a handful of legal entities, especially across countries with different currencies, statutory frameworks, and tax rules. F&O's shared master data (data-sharing policies, global address book) and its per-entity posting layers were built for this.

Deep manufacturing. Process manufacturing with formulas, co-products, batch attributes, and catch weight. Advanced discrete manufacturing with engineering change management and configure-to-order. Manufacturing execution integration. BC has light manufacturing; F&O has enterprise manufacturing.

Advanced warehousing. Directed put-away and picking, wave and load management, license plate tracking, cluster picking, high-volume warehouse operations. BC has basic warehousing; F&O's Advanced Warehouse Management is a serious WMS in its own right.

Retail / commerce. POS, e-commerce, clienteling — Dynamics 365 Commerce runs on F&O infrastructure. If the business is retail-first, F&O is the platform whether or not the finance workload alone would justify it.

Regulatory complexity. Public sector, defence contracting, life sciences with FDA validation, industries with heavy audit and reporting requirements. F&O's localisation depth, Electronic Reporting framework, and audit trail were built for this workload.

Internal platform capability. F&O implementations succeed when there is an internal team who own the platform — configuration, governance, upgrades, integrations. Without that team, even the best SI can only carry the deployment so far. If the business does not have and will not build that capability, F&O will be a mismatch regardless of the requirements.

Where the choice is genuinely hard

The middle zone — say 100 to 500 users, one to five legal entities, moderate complexity — is where both platforms plausibly work. What breaks the tie:

Is the operational complexity growing? If the business is growing into more entities, more countries, more product complexity, F&O's ceiling matters more than BC's speed. If the business is stable in shape, BC's simpler operating model wins.

Is there a manufacturing story? BC can handle light manufacturing but the depth ends quickly. If manufacturing is central and non-trivial, lean toward F&O even at lower headcount.

How much integration to Microsoft business apps? Both integrate to Sales, Customer Service, Marketing, Copilot Studio. F&O has Dual-write for real-time bidirectional sync to Dataverse; BC uses connectors and Power Automate flows. For deep integration to the CRM apps, F&O has the edge.

How mature is the internal IT team? F&O demands more platform maturity from the customer. A team that runs a couple of SaaS applications well is BC-ready; F&O needs the muscle to run a genuine enterprise platform.

What the migration looks like

The "we've outgrown BC" migration to F&O is a re-implementation, not an upgrade. There is no in-place migration path — the data models, the extensibility model, and the tooling are fundamentally different.

Typical shape:

1. Business case and platform decision. Six weeks to three months. Confirms F&O is the target and quantifies the change.
2. Design and build. Six to eighteen months, depending on scope. A global template gets built, tested against the current business processes, and refined.
3. Data migration. Master data (customers, vendors, items, chart of accounts) moves first, transactional data last. History typically stays in BC in read-only form; only current-year balances and open transactions move.
4. Cutover. A weekend cutover for a single entity, phased for multi-entity groups.
5. Steady state. F&O runs on the Wave release cadence like BC — but the internal team has to keep up with a much larger platform.

Ten-plus months from signature to go-live is typical for a mid-size migration; twenty-four months is not unusual for a global template. Budget rule of thumb: the F&O implementation costs 3–10× a comparable BC one.

Because of that cost profile, "migrate to F&O" is almost never the right answer if BC still meets the requirements. Force the "why now" question. The best migrations are triggered by concrete requirements BC cannot meet — a new acquisition adding twenty entities, a manufacturing site whose complexity BC cannot model, a compliance regime that BC's localisation does not cover.

Running both

Some groups run both. F&O centrally for the large entities where the depth is needed, BC in smaller subsidiaries where a full F&O footprint is overkill.

Microsoft's guidance in this scenario is that BC subsidiaries consolidate into F&O for group reporting through standard integrations, and that the manufacturing / operational depth stays where it belongs. It is a valid pattern for global groups; it also adds an integration layer that has to be owned by someone.

The short version

Pick BC when the business is under a few hundred users, has straightforward operations, wants a fast implementation, and does not have — or want to build — an internal ERP platform team.

Pick F&O when the business runs across many entities and countries, has deep manufacturing or warehousing, sits in a regulated industry, or already has the internal muscle to own an enterprise platform.

In the middle, force the "what specifically about the operations requires F&O" question. If nothing specific requires it, BC almost always wins on total cost of ownership.