Going live is the easy part to budget for. What decides whether Business Central keeps serving your finance team and your accountant over the years is the support and maintenance arrangement behind it. Many UK companies discover only after go-live that nobody was clearly responsible for the second Tuesday of an update cycle, a failed integration or a payroll export that stopped working.
This page sets out how support for Business Central is divided between Microsoft and your implementation partner, what a sensible maintenance contract contains, how updates affect you, what to put in the budget and how to move to another provider if the relationship is not working.
Who supports what: Microsoft, the partner and you
Business Central is not supported through a single helpdesk. Microsoft's model is built around the partner. Every customer has a partner that provides first-line technical support: it receives the request, investigates it and escalates to Microsoft only if the cause lies in the platform itself. To do so it acts as a delegated administrator of your tenant.
There is a catch worth knowing about. For a partner to raise a case with Microsoft on your behalf, it must be a delegated administrator and hold an Advanced or Premier support plan. A very small reseller without that plan can take your call but cannot always push a platform problem upwards. Ask the question before you sign.
For on-premises deployments, Microsoft's own help pages do not list a technical support contact. Instead, the partner agrees with your administrator how and when to be contacted, which is one more reason to write the arrangement down.
| Topic | Microsoft | Your partner | Your own team |
|---|---|---|---|
| Platform incidents (break-fix) | Investigates and fixes | Qualifies, raises and follows up | Reports with clear evidence |
| How-to and usage questions | Not covered; training is the route | Answers or trains, depending on contract | Key users first, then partner |
| Corrupted data | Does not help correct it | Can propose a clean-up as a chargeable job | Validates the result |
| Monthly and major updates | Publishes and schedules them | Tests, adapts extensions, advises | Signs off in a sandbox |
| Extensions and customisation | Out of scope | Maintains, or the extension vendor does | Decides priorities |
| Integrations with other systems | Out of scope beyond the platform | Monitors and repairs, if in scope | Owns the business rules |
The last two rows catch people out. Anything built on top of the standard product, such as a bespoke extension or a connector to your e-commerce platform, only has a maintenance owner if a contract says so. Our page on customisation in Business Central explains why custom code needs a named owner from the day it is delivered.
What Microsoft does and does not cover
Microsoft's technical support deals with incidents on the product: something that should work as documented and does not. It does not cover usage questions, which Microsoft treats as a training matter, and it does not repair corrupted data. In practice that means the day-to-day load of "how do I post this credit note?" and "why is this ledger entry wrong?" lands on your partner or your key users.
Microsoft also looks after the platform's safety net. An online environment can be restored to any point in the last 28 days, up to 10 times in a calendar month, within the same Azure region and localisation, and only with a paid subscription. That is useful after a failed data import or a mistaken bulk update, but it is a tool for a partner or administrator to use deliberately, not a substitute for a tested recovery procedure.
What the partner should cover: support, application management and change
Contracts are easier to compare when you separate three kinds of work.
Support (incident handling)
This is the reactive service: users report a problem, the partner logs, prioritises, fixes or escalates. Ask how requests are raised (portal, email, phone), who answers, and whether a named consultant who knows your set-up is involved or whether you reach a rota.
Application management and maintenance
Some partners and buyers call this managed support or application management; French-speaking vendors say TMA. Whatever the label, it is the planned, preventive work that keeps the system healthy:
- testing each update against your own processes before it reaches production;
- keeping extensions and integrations compatible with new versions;
- reviewing user permissions, number series, dimensions and workflows as the business changes;
- monitoring failed jobs, integration queues and scheduled tasks;
- advising on new standard features before you pay for custom development.
Change and enhancement
New reports, an extra approval step, a new warehouse, a second legal entity: these are projects, not support. They should be quoted separately, usually on a time-and-materials basis against a capped pot, so that routine fixes do not quietly eat the improvement budget. If your needs go beyond configuration, see how customisation is handled, and for new modules consult the implementation page.
Updates: the part of maintenance you cannot opt out of
Business Central online follows Microsoft's Modern Lifecycle Policy: the service is updated continuously, with a major update every six months. Two major releases arrive each year, in April and October, and minor updates appear each month when there is no major one. They carry critical fixes and regulatory changes, which matters in the UK where tax rules and filing formats move.
The rhythm of a major release is predictable:
- Preview sandboxes open about a month before the release, in March and September, and are deleted 30 days after general availability.
- The update period starts at general availability, normally the first working day of April or October, and lasts five months.
- The version is offered to existing environments about a week after release, followed by a grace period of a month.
Each environment has an update window, by default between 8 pm and 6 am local time. Your administrator can change it, but it must last at least six hours. Updates that do not finish inside the window are cancelled and rescheduled seven days later. If you run a month-end close late in the evening, set the window around it rather than discovering a conflict.
What this means for your support contract:
- A test cycle for every major release. Your partner should open a preview sandbox, run your key scenarios (sales invoicing, VAT return, bank reconciliation, purchase approvals) and report issues before the production update.
- Extension compatibility. Third-party apps from the marketplace and your own extensions must be ready before the update period closes.
- Release notes read for your business. Not every change matters to you; the partner should tell you which ones do, notably anything touching tax, e-invoicing or payroll interfaces.
- A named sign-off. Someone on your side approves the sandbox results. Without that, the partner is guessing.
For the wider picture of editions and releases, see our page on Business Central versions and editions, and for how the cloud service is operated, the page on hosting and cloud.
UK-specific support points
Some of the incidents you will actually raise are tied to British obligations. A good partner is expected to handle them without a long explanation:
- VAT and Making Tax Digital. After an update, the VAT submission process must still send what HMRC expects. Test it, do not assume it. Our guide to Making Tax Digital and your ERP sets out what to check.
- Year-end and accountant access. Your accountant needs the right permissions, and period closing must be tested before the year-end rush, not during it.
- Payroll links. If payroll runs outside Business Central, the journal export and any real-time reporting handoff belong in the monitoring scope.
- Multi-site operations across the nations. A business with sites in Scotland, Wales and England needs support hours and contacts that match how it actually works, not a single office rota.
Contract terms and service levels to ask for
A support contract without defined terms is a goodwill agreement. When you compare quotes, ask each partner to answer the same list in writing:
| Term | What to ask |
|---|---|
| Hours of service | Which hours and days are covered, and how UK bank holidays are treated |
| Priority levels | How a blocked month-end differs from a cosmetic report fault, and who decides |
| Response and resolution targets | Targets per priority, and how they are measured and reported |
| Escalation | Who you call when the first answer is not enough, and how the partner escalates to Microsoft |
| Named contacts | Who knows your set-up, and what happens when they leave or are on holiday |
| Scope | Standard product only, or also extensions, integrations, reports and the environment itself |
| Updates | Whether testing each major and monthly release is included or billed per release |
| Reporting | Regular reporting on tickets, recurring causes and time spent |
| Exit | Notice period, return of documentation and access, handover help |
Response targets are not resolution targets, and a quick acknowledgement means little if fixes are slow. Ask for both, and ask for the previous quarter's real figures from a reference customer of a similar size rather than the brochure promise.
What to budget for
Do not rely on a single "maintenance percentage". The cost of keeping Business Central healthy is made of several different lines:
- Licences. Microsoft publishes Essentials at 80 USD, Premium at 110 USD and Team Members at 8 USD per user per month, billed annually, on its US page. Those prices can differ by currency, country and regional variant, and the final price appears at checkout, so ask for the sterling quote. Our page on Business Central pricing goes through the licence side.
- Support and maintenance retainer. The recurring fee to the partner. It depends on the number of users, extensions, integrations and legal entities, and on the service levels you choose.
- Update testing. Sometimes inside the retainer, sometimes billed per release. Either is fine if it is written down.
- Change requests. A separate pot for improvements, reports and new processes.
- Third-party apps. Marketplace extensions have their own subscriptions and their own support lines.
- Training. New joiners and role changes continue to need onboarding. See the page on Business Central training.
- Internal time. A key user or super-user who owns requests and tests updates. This is the line most often forgotten.
A helpful discipline is to ask for the retainer and the change budget as two figures. If you receive one blended figure, you cannot tell afterwards whether you are paying for stability or for new features.
Warning signs that your current support is not working
Before changing provider, check whether the symptoms are really about the contract:
- the same incidents return after each update;
- tickets are closed with a workaround and never with a cause;
- only one person at the partner understands your set-up;
- you hear about an update when it has already happened;
- nobody can tell you which extensions you run and who maintains them;
- invoices for "support" cannot be matched to tickets.
If several apply, an independent look is cheaper than a long argument. An audit of the Business Central environment shows what is installed, what is custom, what is fragile and what a new partner would inherit.
How to change Business Central support provider
Moving support is common and less risky than companies fear, provided it is done in the right order.
- Check your contract. Look at notice periods, minimum terms and what the partner must hand over on exit. Ask for a copy of any documentation they hold.
- Build the inventory. List users and roles, extensions and their owners, integrations, scheduled jobs, reports, open tickets and known defects. If the incumbent will not help, an audit can rebuild most of it from the environment.
- Check administrative access. Delegated administration is what ties a partner to your tenant. The new partner needs it, and the old one should have it removed at the agreed date, not before.
- Write the new scope and service levels. Use the table above, and ask each candidate for the same items. Our guide to choosing a Business Central partner covers what to look for in the partner itself.
- Plan a handover period. The outgoing partner remains reachable for questions, ideally through one full update cycle, so that surprises can be explained.
- Test before you rely on it. Run one update in a sandbox with the new partner before the first live release.
Avoid changing provider in the middle of a year-end close, a stock take or a major release window. If you are also considering a different product, the page on Business Central alternatives puts that choice in context.
How we can help
ERP Integrator is a free introduction service. We do not provide support ourselves and we are not affiliated with Microsoft. You describe your Business Central environment, the support you have today and what is not working, and we put you in touch with an integrator suited to your size, sector and region. The integrator then proposes its own support terms, so you can compare them against the checklist on this page. Our guide on choosing an ERP integrator explains how to run that comparison.
Frequently asked questions
Who provides support for Business Central in the UK, Microsoft or my partner?
Both, in a set order. Your partner is the first line: it takes your requests, works on them and escalates to Microsoft when the problem sits in the platform. Microsoft deals with break-fix incidents on its own product, but not with usage questions or corrupted data.
What is the difference between support and maintenance on Business Central?
Support answers incidents and questions as they arise. Maintenance, often sold as application management, is the planned work: testing and applying updates, keeping extensions compatible, housekeeping and small improvements. Many UK contracts bundle the two, but they should be priced and reported separately.
Do I still need a support contract if Business Central is in the cloud?
Yes. Microsoft runs the service and publishes updates, but it does not know your chart of accounts, your Making Tax Digital set-up, your extensions or your integrations. Someone has to test each update against your own processes and answer your users, and that is the partner’s role.
How do I change Business Central support provider?
Start with a handover pack: a list of extensions, integrations, customisations, users and open issues, plus access rights. Your new partner should review the environment before taking over, ideally with an audit, and the outgoing partner should stay reachable until the first update cycle has passed cleanly.
What should I budget for Business Central support and maintenance?
Budget separately for licences, a recurring support and maintenance retainer, and a pot for change requests. The retainer depends on the number of users, extensions and integrations, so ask each partner to price against the same written scope. The licence prices Microsoft publishes cover the software only, not the partner’s service.
Sources
- Microsoft Learn — Technical support for Business Central
- Microsoft Learn — Update rollout timeline
- Microsoft Learn — Managing updates in the admin centre
- Microsoft Learn — Restoring an environment
- Microsoft Dynamics 365 — Business Central pricing
Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.