Dynamics 365 vs Business Central looks like one decision and is really two. Both names come from Microsoft, both get called “Dynamics”, and both are sold as the answer to running your business on one platform. That shared branding is exactly why the choice gets muddled. Picking the wrong one is expensive in a way that shows up eighteen months later, not in month one. Here is how we frame the decision when a client asks us which way to go.
Key takeaways
- Business Central is a single ERP product for small and mid-size companies. Dynamics 365 is a family of separate applications, one of which is an enterprise-grade ERP.
- The honest comparison is usually Business Central against Dynamics 365 Finance and Supply Chain Management, not against “Dynamics 365” as a whole.
- Scale alone does not decide it. Process complexity, number of legal entities, and manufacturing or warehouse depth matter more than headcount.
- CRM is a separate decision. Sales and Customer Service pair with either ERP.
- Licensing is the smallest part of the total cost. Migration, integration, and ongoing change absorb most of the budget.
- Most failed implementations fail at the integration layer, not in the ERP itself.
What the two names actually refer to
Dynamics 365 Business Central is one product. It covers finance, purchasing, sales, inventory, project accounting, and light manufacturing, and it is aimed at companies that want a complete ERP without an enterprise programme to install it. It descends from Navision, which is why teams who ran NAV for years find the concepts familiar.
Dynamics 365 is not one product. It is a family: Sales, Customer Service, Field Service, Marketing, Finance, Supply Chain Management, and more. Each is licensed separately and each can be deployed on its own. When someone says they are “evaluating Dynamics 365” they usually mean one of two things, and it is worth establishing which before any comparison starts.
So the real question is almost always one of these two. Business Central against Dynamics 365 Finance and Supply Chain Management, if you are choosing an ERP. Or Business Central against a Dynamics 365 CRM application, if what you actually need is customer management rather than a general ledger.
Dynamics 365 vs Business Central: the question that decides it
Headcount is the metric everyone reaches for and the least useful one on its own. A 90-person contract manufacturer can be a worse fit for Business Central than a 600-person consultancy. What matters is how complicated your processes are, and how many of them are genuinely unusual.
Signs Business Central is the right fit
- One legal entity, or a handful with straightforward intercompany posting.
- Finance, inventory, and purchasing that look broadly like everyone else’s, even if the products do not.
- Manufacturing that is assembly or light production rather than multi-plant scheduling.
- A preference for configuring a standard product over building your own processes into software.
- An implementation you want measured in months rather than years.
Signs you need Dynamics 365 Finance and Supply Chain Management
- Many legal entities across several countries, with consolidated reporting and local statutory requirements in each.
- Warehouse management with real depth: wave picking, complex putaway strategies, automation on the floor.
- Manufacturing with multi-site planning, subcontracting, or genuine production scheduling constraints.
- Transaction volumes high enough that performance is a design consideration rather than an afterthought.
- A finance function that already runs processes Business Central would need heavy extension to support.
If you read both lists and recognise yourself in the first one, the decision is usually easier than the sales conversation suggests. Our Microsoft Business Central development services exist for exactly that group, where the platform fits and the work is in configuration, extensions, and data.
Where CRM fits, and why it is a separate decision
Sales and Customer Service sit alongside either ERP. Coupling the two decisions is a common mistake, because it turns a manageable CRM rollout into a dependency on a much larger ERP programme. Plenty of companies run a Dynamics 365 CRM application against Business Central, or against an ERP from another vendor entirely, and the integration is well-trodden ground.
Decide CRM on its own merits: the sales process you actually run, the reporting your commercial team needs, and how much of the customer record has to be visible in finance. Our Microsoft CRM development services cover that side, including the integration back into whichever ERP you land on.
The costs people miss
Per-user licensing is visible, comparable, and easy to put in a spreadsheet, which is why it dominates early conversations. It is rarely the number that decides whether the project was worth doing. The costs that move the total are these.
- Data migration. Consistently underestimated. Legacy data is never as clean as the discovery workshop suggests, and the cleanup is business work, not just technical work.
- Integration. Every system that has to talk to the ERP is a project of its own, with its own testing and its own failure modes.
- Extensions and ISV add-ons. Each one is a dependency you carry through every future upgrade.
- Change management. The cost of people learning new processes is real even though it never appears on a licence invoice.
- Ongoing development. The system is not finished at go-live. Budget for the year after, not just the project.
Integration is where projects actually fail
In our experience the ERP itself is rarely the thing that sinks an implementation. What sinks it is the web-shop that has to post orders, the warehouse scanners that have to reserve stock, the payroll system that has to feed the ledger, and the reporting tool that has to read all of it consistently. Each of those is an interface with its own edge cases.
Map every external system before a single connector is written, and decide for each one whether it is real time or batch, who owns the record, and what happens when the other side is down. That is the work behind our API development services, and it is worth doing during selection rather than after.
How to de-risk the decision
You do not have to guess. Three things reliably reduce the risk before you commit.
- A fit-gap against your real processes. Not a demo of the product working perfectly, but a walk through the five processes that are genuinely unusual in your business.
- An audit of what you already have. If you are moving off NAV, or off a heavily customised system, the existing customisations tell you what will and will not survive. That is what a code audit is for.
- A small proof on real data. One process, one integration, your own records. It answers more questions than another round of vendor demos.
Staffing matters too. If the implementation partner does everything and your own people learn nothing, you will be dependent on them for every change afterwards. A dedicated development team or a structured software development outsourcing arrangement can keep capacity available without that lock-in, and our Dynamics 365 developers work in both models.
Frequently asked questions
You can, but do not plan for it as a cheap upgrade path. They are different products with different data models, so it is a second implementation rather than a migration. Choose for where the business will be in three to five years, not just for today.
No. It runs comfortably in companies of several hundred people. The limit is process complexity rather than size, which is why the two lists above are about how you operate rather than how many people you employ.
A focused rollout for a single entity with a few integrations typically runs three to six months. Multi-entity, heavy migration, or unusual manufacturing pushes that out. The variable that moves the timeline most is data readiness, not software configuration.
Most companies need help for the first implementation and then want to be self-sufficient for changes afterwards. That is a reasonable goal, and it is worth stating it explicitly at the start so the partner builds your team’s knowledge along the way instead of around it.
Bottom line
Establish which Dynamics 365 product you are actually comparing, then decide on process complexity rather than headcount, then budget for migration and integration rather than licences. Keep the CRM decision separate. Prove the awkward parts on real data before you commit.
If you want a second opinion on which platform fits how you operate, talk to us. We will look at your processes and tell you plainly which one we would choose and why.
