Dynamics 365 Business Central is usually the better choice for small and mid-sized companies already using Microsoft 365, with finance, sales, purchasing and inventory processes close to common practice. A custom ERP wins when your core operations fall outside Business Central's model and the extensions you would need become the real system, maintained through every Microsoft update. The test is how much of your business would live in extensions.
Business Central is Microsoft's ERP for small and medium businesses, available as a Microsoft-run cloud service and widely implemented by partners in the US, UK and UAE. A custom ERP is software designed around your workflows, built module by module and owned by you. This guide covers how Business Central is extended, what its update cycle means for custom code, and where a custom build makes more sense.
If you have already chosen Business Central and need it connected to other systems, our ERP integration services page covers that work. If your gap analysis shows the core process does not fit, our custom ERP software page explains how we build module by module.
Why does the Microsoft ecosystem matter in this decision?
For many companies, the main argument for Business Central is not a single feature but its fit with tools they already use.
Business Central is part of the Dynamics 365 family and connects with other Microsoft products. Companies that run on Microsoft 365, Teams and Power BI often value having finance and operations in the same ecosystem, with familiar sign-in and administration. Microsoft partners are also widely available in all three markets.
That benefit is real, but it should not decide the question on its own. A custom ERP can also sign users in with Microsoft accounts, publish data to Power BI and connect to Microsoft 365. Ask what you would gain from Business Central beyond integration that a custom system could also provide.
How do you customize Business Central?
Business Central is customized through extensions written in AL, Microsoft's language for Business Central, using Visual Studio Code. Extensions add to standard objects rather than editing the base code.
Microsoft's developer documentation (checked October 2026) describes extensions as a programming model in which you define functionality as an addition to existing objects. Developers create new tables, pages, reports and codeunits, and use table and page extension objects to add fields and behaviour to standard ones. Extensions are compiled into .app packages and deployed to the environment. Microsoft also offers an in-client Designer for simpler page changes.
There are broadly two kinds of extension:
- Per-tenant extensions: built for one customer, usually by their partner
- Marketplace apps (historically AppSource): products submitted to Microsoft's marketplace by independent vendors after a validation checklist
The extension model is a strength. It keeps custom code separate from Microsoft's, which makes updates more predictable than editing a core system. It also has limits: you can only change behaviour where Microsoft's code allows extension, and your logic still sits on Business Central's data model and posting routines.
What does the update cycle mean for custom code?
Business Central online is updated by Microsoft on a regular schedule, and every extension you own must keep working through those updates.
Microsoft's documentation describes major updates twice a year, in spring and autumn, with minor updates in between, and gives administrators a window to schedule each update. Microsoft-run updates mean you are always on a supported version, which is a genuine benefit. The cost is that each update must be tested against your extensions and Marketplace apps before it reaches production.
Plan for:
- A sandbox environment where updates and extensions are tested first
- Automated tests for each per-tenant extension
- A named owner, usually your partner, responsible for update readiness
- A check that every Marketplace app you rely on supports the new version
With a light set of extensions, this is routine. With a large one, it is a recurring project.
When does a custom ERP win over Business Central?
A custom ERP wins when the work your business is built on is not something Business Central models, so the extensions would carry most of the value and most of the risk.
Typical cases:
- Operational complexity beyond the ledger: job-shop production, construction projects, installment or rental contracts, or service operations with complex scheduling
- Many light or mobile users who need focused apps rather than full ERP access
- Specific regulatory or public-sector workflows, including bilingual Arabic and English flows, where the process is fixed and must be followed exactly
- A data model that does not map to Business Central's documents and ledger entries
- A strategic need to own the platform, its hosting and roadmap
Many companies choose a hybrid: Business Central for finance and standard supply chain, and a custom application for the operational core, linked by APIs. Our guide to system integration approaches explains how to design those links.
How do you run a fair gap analysis for Business Central?
A fair gap analysis tests Business Central against your real workflows with your own data, and sorts every gap by how it would be closed. It is the single most useful input to this decision.
Run it in five steps:
- Pick the ten workflows that matter most, such as quote to cash, purchase to pay, stock transfer, month-end close and any process unique to your business.
- Write each as a script with real examples: a typical order, an awkward order, a return, a partial delivery, a credit note.
- Ask the partner to run the scripts live in a sandbox loaded with a sample of your items, customers and prices, not the demo company.
- Record every gap and how the partner proposes to close it: configuration, Designer change, Marketplace app, per-tenant extension, or a separate application.
- Mark which gaps touch posting, costing or tax, because those carry the most update and audit risk.
Then do the same exercise for a custom build: ask the developer to walk through how each scripted workflow would work, and which modules a pilot would cover. Comparing two lists of gaps and closures is far more reliable than comparing two presentations.
A useful rule of thumb from this exercise: if most gaps close with configuration and Marketplace apps, Business Central is likely the right fit. If the gaps that remain are in the workflows that make your business money, look hard at a custom or hybrid design.
Business Central vs custom ERP: decision table
| Question | Points to Business Central | Points to custom ERP |
|---|---|---|
| Existing tools | Heavy Microsoft 365 use, Power BI in place | Mixed stack, or Microsoft fit not a priority |
| Core processes | Close to standard finance, sales, purchasing, inventory | Unusual operations that drive the business |
| Gap coverage | Gaps met by configuration and a few extensions or Marketplace apps | Many per-tenant extensions, several touching posting logic |
| Users | Mostly office-based | Many mobile, field or shop-floor users |
| Update appetite | Happy to follow Microsoft's schedule | Need to control release timing |
| Ownership | Comfortable with a partner and Microsoft roadmap | Want to own code, data model and hosting |
| Partner availability | Good local partner with industry references | Partners lack experience in your process |
Worked example (illustrative)
Consider a UAE trading company with a showroom, two warehouses and a service department. Finance, purchasing, inventory and sales fit Business Central with configuration. VAT reporting is handled through the localization or a local partner's app, and sales staff already live in Microsoft 365. This is a good Business Central case.
Now add a large after-sales service operation: technicians scheduled across the country, parts consumed on site, customer sign-off on a tablet, and service contracts with tiered response terms. If those needs require many per-tenant extensions plus a separate mobile app, a better design might keep Business Central for finance and inventory and build a custom service platform that posts parts usage and invoices into it. This example is illustrative, not a client case.
When is custom the wrong answer?
Custom is the wrong answer when your requirements are standard, when a Marketplace app already solves your gap, or when the business cannot commit people to define and test what gets built.
Also be cautious if the main motivation is cost. A custom ERP has no per-user licence, but it does have build, hosting, support and enhancement costs. Compare over five years: licences or build cost, partner or developer fees, hosting, update testing, support, enhancements and the internal time your team spends on each option.
Checklist before you choose
- Run a scripted demo of Business Central against your top ten workflows
- Sort every gap into configuration, Marketplace app, per-tenant extension or custom application
- Count the extensions that would touch posting or costing logic
- List users by role and how often each needs the system
- Confirm who owns extension source code in the partner contract
- Ask the partner how update testing works and what it costs
- Map every integration and decide which system owns each record
How to start
Prepare a short requirements brief before talking to partners or developers; our software requirements brief template gives you the headings, and the ERP selection criteria checklist helps you score options consistently. If a similar decision involves other packages, see our comparisons of Odoo vs custom ERP and NetSuite vs custom ERP.
When you are ready, discuss the project with us. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, so you can compare working software built around your process with a Business Central demo. If you decide on Business Central, our ERP implementation services team can help with rollout and data migration.