Business Central Support: What Microsoft Actually Covers
The Ticket That Goes Nowhere
A finance manager opens a Microsoft support ticket because a customized approval workflow in Business Central stopped triggering correctly after an update. Days later, the ticket closes with a note that the issue traces to custom code and the case is being handed back. Nobody did anything wrong. This is exactly how Microsoft's support model is designed to work, and almost no one explains that design before a business needs it.
"Support" Means Something Narrower at Microsoft Than It Does to You
Microsoft's own documentation on technical support for Business Central defines support in a specific, limited way: break-fix issues, meaning technical problems that occur during normal use in a standard Cronus database environment and require Microsoft's support team to restore the system to working order.
Two things sit outside that definition by design. First, how-to questions, meaning a user not understanding how a feature works, are classified as training and advisory territory, not a support case, even though they arrive at the help desk looking identical to a genuine break-fix problem. Second, and more consequential, is the phrase "standard Cronus database environment." Cronus is Microsoft's demo company.
If a problem cannot be reproduced there, meaning it depends on your specific customizations, your specific data, or your specific configuration, Microsoft's support team applies best effort, and if the issue is not resolved, the case closes with a recommendation to consult a partner or the community forums.
Your Partner Is the Frontline, Not a Fallback
The same Microsoft documentation states plainly that every Business Central customer has a partner who serves as the frontline of technical support. That partner triages incoming requests, investigates, and either resolves the issue directly or escalates it to Microsoft. This is not an optional layer some businesses choose to add. It is how the support model is structured from the start, which means the quality of that first-line relationship, not Microsoft's own support desk, determines how quickly most issues actually get resolved.
A business that treats its partner as a project vendor it calls only during implementation, rather than an ongoing support relationship, is missing the layer that Microsoft's own architecture assumes will catch nearly everything before Microsoft needs to get involved at all.
Four Things Microsoft's Support Will Not Fix
Reading the technical support documentation closely surfaces a specific list of exclusions worth knowing before, not during, an incident. Custom code, meaning AL extensions and modifications built for your business, sits outside standard support once the root cause traces there; Microsoft's team will provide evidence pointing to the custom code so the customer or partner can take it from there.
The same applies to partner or ISV software, meaning any third-party app installed from AppSource. Environmental factors, such as network configuration or integration with systems outside Business Central, fall into the same category. And data corruption is explicitly excluded on legal grounds, not just practical ones: Microsoft's documentation states plainly that correcting damaged data is not something Microsoft does, and cites the Service Provider License Agreement as the basis for having no legal obligation to fix data corrupted by malfunctioning software.
For a finance team, that last point deserves particular attention, since it means a bad journal batch or a corrupted posting caused by custom code or a bad integration is a partner-and-backup problem, not something a Microsoft ticket resolves.
The Escalation Gate Nobody Explains Upfront
Even when an issue clearly is a break-fix case inside standard functionality, escalating it to Microsoft is not automatic. Microsoft's documentation is specific: to submit a support request on a customer's behalf, a partner needs delegated administrator access to that customer's tenant, and the partner's own company needs to hold an Advanced or Premier support plan with Microsoft.
A partner without that plan tier cannot open a Microsoft ticket at all, regardless of how legitimate the issue is. This is a detail worth confirming directly with your support provider rather than assuming, since it determines whether a genuine Microsoft-side bug in your environment has an actual escalation path or dead-ends at your partner's own troubleshooting capability.
Staying Supported Is a Choice You Make Every Update Cycle
For on-premises Business Central deployments, Microsoft's software lifecycle policy makes support conditional on staying current. Under the Modern Lifecycle Policy, which covers 2019 release wave 2 and later, Microsoft supports the software only if the customer keeps the deployed version current according to that policy; the customer controls when updates are installed, but falling behind on that schedule can put a deployment outside supported status even though nothing about the software itself has changed.
This is a genuine business continuity consideration for on-premises customers specifically, since it means a decision to defer an update for operational convenience is also, quietly, a decision about whether that environment remains eligible for Microsoft support if something goes wrong later.
Confirm your specific version's status against Microsoft's lifecycle documentation directly, since policy details and dates are updated by Microsoft over time.
Where Businesses Get This Wrong in Practice
We see the same handful of mistakes across engagements. Businesses call Microsoft first for issues that are clearly customization-related, losing days to a ticket that was never going to resolve there, when the same issue would have gone straight to a partner developer who wrote or maintains the customization.
Businesses assume their support partner automatically has Advanced or Premier standing with Microsoft and can escalate on demand, without ever confirming it. On-premises customers defer version updates for a full fiscal year or more to avoid disrupting a busy season, without realizing that decision affects their support eligibility, not just their feature set.
And businesses treat data backup as a Business Central administration task rather than a support prerequisite, discovering only after a corruption event that Microsoft's support plan was never going to be the fix, no matter which tier they held.
Building a Support Model That Actually Holds Up
Confirm in writing what support tier your partner holds with Microsoft and what that means for escalation, before an incident forces the question. Separate your understanding of "support" into the categories Microsoft actually uses: break-fix in standard functionality, advisory or training for how-to questions, and everything involving custom code, ISV apps, or data integrity, which is your partner's direct responsibility regardless of what Microsoft's ticket queue says.
For on-premises deployments, treat the update cadence required by the Modern Lifecycle Policy as a support continuity decision, not just a change management one, and calendar it accordingly.
Maintain a backup and data integrity discipline independent of any support plan, since no tier of Microsoft support restores corrupted data. And review your support plan at least annually against how your Business Central environment has actually changed, since a support arrangement sized for a vanilla implementation stops fitting once customizations and integrations accumulate.
The Short Version
Microsoft's direct support covers break-fix issues reproducible in a standard demo environment, and explicitly excludes custom code, ISV software, environmental factors, and data corruption. Every Business Central customer's actual frontline of support is their partner, not Microsoft, by design. Escalating to Microsoft requires the partner to hold an Advanced or Premier support plan and delegated admin access, a detail worth confirming before you need it. On-premises customers must stay current with the Modern Lifecycle Policy to remain support-eligible at all, independent of whether anything is currently broken.
Next Step
If you have never confirmed what your current support arrangement actually covers, or what support tier your partner holds with Microsoft, that is worth a direct conversation before an incident forces it. Dynamics Square's Dynamics 365 support services in the US are built around exactly this gap, handling the customization, integration, and data-level issues that sit outside Microsoft's direct support boundary, and our teams in the United Kingdom and Canada run the same model for businesses operating in those markets.
FAQ
Does Microsoft provide direct support for Business Central?
Yes, but only for break-fix issues that can be reproduced in a standard Cronus demo environment. Every Business Central customer also has a partner who serves as the frontline of support, triaging and resolving most issues before Microsoft needs to be involved at all.
Will Microsoft fix a problem caused by our custom Business Central code?
Not directly. Microsoft's support team will investigate and, if the root cause traces to custom code, partner software, or environmental factors, provide evidence of that so your partner can take over resolution. This is explicitly outside the scope of standard break-fix support.
Does Microsoft support cover data recovery if our Business Central data gets corrupted?
No. Microsoft's documentation states plainly that correcting corrupted data is not part of its support obligation, citing the Service Provider License Agreement. Data integrity and recovery are the customer's and partner's responsibility, which is why backup discipline matters independent of any support plan.
What happens to support if we fall behind on Business Central on-premises updates?
Under the Modern Lifecycle Policy, Microsoft supports on-premises Business Central only if the deployment is kept current according to that policy. Falling behind on updates can move a deployment outside supported status even if nothing else about it has changed.
Does Dynamics Square offer Business Central support in the US, UK, and Canada? Y
es. Dynamics Square provides Business Central support services across the United States, United Kingdom, and Canada, covering the customization, integration, and ongoing optimization work that sits outside Microsoft's direct break-fix support.