Every Business Central implementation cost conversation starts in the same place, which is the per-user price, because it is the only number anyone publishes. It is also the least useful number in the business case, and treating it as the anchor is why so many of these projects are budgeted wrong.
Microsoft publishes the licensing clearly. Everything else that determines what the project costs is in an implementation guide most buyers never open.
What Microsoft actually publishes
The published pricing is short, which is unusual and welcome:
| Plan | Price | Basis |
| Essentials | $80.00 per user per month | Paid yearly |
| Premium | $110.00 per user per month | Paid yearly |
| Team Members | $8.00 per user per month | Paid yearly |
There is a 30 day trial. And Microsoft attaches a caveat worth repeating rather than skipping: prices shown are for informational purposes only and may not reflect actual list price, because of currency, country and regional variant factors. So treat those figures as the shape of the commercial model rather than a quote.
The genuinely useful part of this table is the $8.00 Team Members line, because it is the one most often left out of a first estimate. Team Members covers people who need to read data, approve, and enter time or expenses, rather than run the processes. In most organisations that population is larger than the full-licence population, and pricing everyone at Essentials produces a subscription number that is wrong in a way that makes the whole business case look worse than it is.
Essentials against Premium is a narrower decision than it appears. Premium adds service management and manufacturing. If you do not run those, the difference is not a tier you are growing into, it is capability you would be buying and not using.
Even so, the subscription is the smallest of the three cost categories Microsoft itself lists for a Dynamics 365 budget: subscription, storage, and implementation lifecycle activities. It is the third that decides the number.
The ratio nobody puts in the business case
Here is the shape of it, from the engagements we quote.
In a typical mid-market Business Central implementation of 20 to 50 users, licensing accounts for roughly 15% to 25% of total first-year expenditure. Professional services, data migration and extension development consume the other 75% to 85%.
Worked through on a standard 30 user deployment:
| First-year cost | Range |
| Annual subscription licensing | $25,000 to $35,000 |
| Professional services | $80,000 to $150,000 |
That services figure covers discovery, chart of accounts design, integrations, historical data cleansing, user acceptance testing and hypercare. Note that the subscription range is exactly what Microsoft’s published pricing produces: 30 users on Essentials at $80 is $28,800 a year, and the spread either side is the Team Members and Premium mix.
So the per-user price is not a small part of the picture. It is roughly a fifth of it. Framing a Business Central decision around the subscription gives stakeholders a false baseline, because implementation is the primary capital outlay and it is the part nobody publishes a number for.
The practical consequence is about approvals rather than arithmetic. A board that has approved a subscription figure has approved something close to 20% of what the first year costs. That gap is not usually discovered in a spreadsheet. It is discovered in a second approval conversation that nobody planned for, at the point where the project has already started.
The eleven activities that are the actual cost
Microsoft’s implementation guidance contains a list that belongs in every Business Central budget, and it is not presented as a costing tool, which is probably why it does not get used as one. It is the list of activities a statement of work should cover in detail:
- Business process modelling, documentation and management
- User interface and user experience
- Data migration, including sourcing, cleansing, mapping, transforming and importing
- Integration with other line of business applications and external systems
- Test strategy, planning and execution
- Management and orchestration of user acceptance testing
- Security design and role assignment
- Configuration management
- Analytics and business intelligence reporting strategy, tools and design
- Cutover planning and execution
- Adoption and change management
Read that as a cost breakdown rather than a checklist and the picture changes. Two of those eleven are the ones that consistently exceed their estimate in our experience: data migration, because the cleansing is discovered rather than planned, and integration, because the number of systems is always higher than the initial count.
Microsoft is direct about why this list matters commercially, and the reasoning is about contracts rather than technology. Statements of work that describe high-level activities without detail produce “confusion and finger-pointing during the project”, because the customer assumes the partner is handling something and the partner assumes the customer is. The guidance is explicit: the contract should focus on detailed activities with clear definitions of assumptions, roles and responsibilities, and should state what is out of scope.
That last clause is the one to insist on. An implementation quote without an out-of-scope section is not a cheaper quote. It is the same quote with the disagreement deferred.
The extension tail
The second structural cost is the one that arrives after go-live.
Microsoft frames the decision as a balance between delivering faster using built-in capability and extending the product to meet requirements as stated. The part that gets underweighted: extending Business Central “not only requires initial development costs but also maintenance and support costs”.
Business Central ships weekly fixes, monthly updates and two major release waves a year. Every extension you own is something that has to keep working across all of that, indefinitely. A customisation is not a one-off line in the build budget. It is a subscription you pay in maintenance, and unlike the licence it does not appear on any published price list.
This is why the guidance recommends mapping default capabilities to business requirements early, specifically to minimise customisations and make future updates easier without rework. And why it recommends budgeting deliberately for CI/CD pipelines with sufficient automated testing of functional scenarios and business processes. That is not gold-plating. Given the release cadence, regression testing is a recurring operational cost whether or not anyone budgeted for it, and automation is the only thing that stops it growing with every extension.
Worth connecting this back to the ratio above. Extension development sits inside the 75% to 85%, alongside services and migration, which means every customisation agreed in a design workshop is drawn from the part of the budget that was never presented to the board as a number. That is why extensions feel free at the point they are agreed and expensive at the point they are invoiced.
What gets cut, and it is always the same four things
This is the most useful sentence in Microsoft’s guidance and it reads like a warning because it is one.
As scope and timelines move, the activities that fall towards the end of the project lifecycle get cut to meet budget constraints. Microsoft names them: performance testing, data validation testing, training, and change management.
Look at what those four have in common. None of them is required to reach go-live. All four are what determine whether go-live works. Cutting them does not reduce the cost of the project, it moves the cost past the point where anyone is measuring, into a support burden and an adoption problem that nobody attributes back to a budget decision made months earlier.
Data validation testing is the one I would defend hardest. It is the only activity that establishes whether the numbers in the new system match the numbers in the old one. Cut it and you have migrated data you have not verified, into a finance system, which is a category of risk that is very cheap to avoid and very expensive to discover.
The structural fix is not heroism about protecting scope. It is sequencing. If those four activities sit at the end of the plan, they are exposed to every delay that happens before them. Move validation and training earlier, run them in parallel with build rather than after it, and they stop being the natural candidates for the axe.
Our position: the fixed-fee question is the wrong question
We are asked constantly whether a Business Central implementation can be done for a fixed fee. It can, and we offer one, and in our view the more important question is what the fee is fixed *around*.
Scope-first is the only commercially sustainable way to do this. A fixed fee against a well-defined process scope transfers delivery risk to the party that can actually manage it, and it forces the detailed scoping conversation Microsoft’s guidance says most contracts skip. A price-first fixed fee does the opposite: it inevitably produces adversarial change-order battles, because the only variable left to argue about is what was implied.
There is a second effect that is easy to miss and is arguably the bigger one. A scope-first boundary makes the customer’s own budget the thing that keeps them standard. When the fixed fee covers out-of-the-box configuration and everything beyond it is chargeable, the incentive to align internal processes with standard functionality sits with the person who controls the money, rather than with a consultant arguing for best practice in a workshop. That is a far more durable mechanism than persuasion, and it is the reason a well-drawn fixed fee produces less customisation than a time and materials engagement with the same requirements.
So we would not lead with price. In our engagements the projects that land are the ones where the out-of-scope list was written before the number was agreed, and the projects that drag are the ones where an attractive number was agreed first and the scope was inferred afterwards.
The corollary, and this is the part clients push back on: a higher quote with a detailed activity breakdown is usually cheaper than a lower quote without one. Not always, and the difference is not the margin. It is that the detailed quote has already done the thinking about data migration and integration, which are the two lines that move.
The boundary that actually holds
A scope-first fixed fee only works if the line is drawn somewhere defensible. This is the one we use, and it is deliberately blunt, because a boundary that needs interpreting is not a boundary.
| Inside the fixed fee: the standard core | Outside it: time and materials |
| Out-of-the-box core financials: general ledger, accounts payable, accounts receivable, bank reconciliation, fixed assets | Custom AL extensions, meaning any modification to base posting routines or table schemas |
| Standard master data template ingestion: chart of accounts, customers, vendors, items | Third-party integrations: e-commerce, legacy CRM, custom EDI |
| Default document layouts | Data cleansing and transformation |
| Standard security roles | Advanced operational modules: custom manufacturing routing, multi-bin warehouse configuration, service order management |
| Administrator training |
The rule underneath the table is short enough to put in the contract: anything beyond standard configuration and template-based migration moves immediately into a separate, phased statement of work. Not a change request against the fixed fee. A separate piece of work, priced on its own.
The data line is the one worth being explicit about, because it is where fixed-fee engagements most often fail. We provide the Excel migration schema. The client is strictly responsible for populating it with clean data. That division is not us avoiding the difficult part. It is that data quality is a function of institutional knowledge we do not have, and open-ended cleansing is precisely the activity that cannot be fixed-price because nobody can size it in advance. Recall that data migration is one of the two lines that consistently exceeds its estimate.
Read the excluded column again and notice what it is not. It is not a list of things we would rather not do. Every item in it is chargeable work we are happy to quote. It is a list of the things that cannot be sized before someone has looked, which is the only honest basis for what belongs inside a fixed price and what does not.
Where this sits against the rest of the estate
Two connections worth making, because Business Central rarely arrives alone.
If you are moving from an older Dynamics product, the Dynamics migration path changes the data migration line considerably, in both directions. A supported upgrade path removes work. A re-implementation adds the cleansing effort back.
And the subscription sits inside a wider Microsoft commercial position. How you buy it, through licensing and CSP, affects the effective price more than the tier choice does for most organisations, in the same way the Microsoft 365 E7 bundle question turns on what you already hold rather than the headline figure.
Where to start
Do not start by pricing users. Start by counting the eleven activities against your own situation and marking which of them you are assuming somebody else will do.
Then get three specific things onto paper before any number is agreed: how many systems Business Central has to integrate with, what condition the data you are migrating is actually in, and what is explicitly out of scope. Those three answers move the total more than the Essentials against Premium decision ever will.
Veratas implements Business Central on a fixed-fee basis where the scope supports it, and says so when it does not.
If you have a Business Central quote in front of you and no out-of-scope section, talk to our team. That is a short conversation and it usually changes the number in a useful direction.
Frequently asked questions
How much does Dynamics 365 Business Central cost per user? Microsoft publishes Essentials at $80.00 per user per month, Premium at $110.00 and Team Members at $8.00, all paid yearly. Microsoft notes these are informational and may not reflect actual list price because of currency, country and regional factors.
What is the difference between Essentials and Premium? Premium adds service management and manufacturing. If you do not run those processes, Premium is capability you would be buying and not using rather than a tier to grow into.
Who needs a Team Members licence? People who read data, approve, and enter time or expenses rather than run processes. In most organisations that group is larger than the full-licence group, and leaving it out of an estimate overstates the subscription cost significantly.
What drives Business Central implementation cost beyond licences? Microsoft lists subscription, storage and implementation lifecycle activities. The third is the largest, and covers process modelling, data migration, integration, testing, UAT, security design, configuration management, reporting design, cutover and change management.
Why do customisations cost more than the build estimate? Because extending the product carries maintenance and support costs as well as initial development. Business Central ships weekly fixes, monthly updates and two release waves a year, and every extension has to keep working across all of them.
What gets cut when an ERP project runs over budget? Microsoft names performance testing, data validation testing, training and change management. None is needed to reach go-live and all four determine whether go-live succeeds, which is why sequencing them earlier matters more than defending them later.
What proportion of Business Central cost is licensing versus implementation? On a typical mid-market deployment of 20 to 50 users, licensing is roughly 15 to 25% of first-year expenditure and professional services, data migration and extension development make up the rest. For 30 users that is around $25,000 to $35,000 of subscription against $80,000 to $150,000 of services.
What should a fixed-fee Business Central implementation include? Out-of-the-box core financials, template-based master data migration, default document layouts, standard security roles and administrator training. Custom AL extensions, third-party integrations, data cleansing and advanced operational modules sit outside it, because none can be sized before someone has looked.
Who is responsible for cleaning the data we migrate? The client. The partner provides the migration schema; populating it with clean data depends on institutional knowledge the partner does not have, and open-ended cleansing cannot be fixed-price because nobody can size it in advance.
Should we ask for a fixed fee? Yes, provided the scope is defined first. A fixed fee against a clear process scope transfers risk usefully. A fixed fee against an undefined scope moves the argument to change requests rather than removing it.
Senior Business Intelligence Architect with 22 years of experience designing enterprise analytics and data platforms. Focus areas include Power BI, real-time analytics, and large-scale BI architecture across the Microsoft data stack.