Most Business Central projects budget carefully for go-live and hardly at all for the day after. That is a mistake built into the product, not a failure of planning. Microsoft designed Business Central online with the partner as the first line of technical support, and it updates the product on a fixed calendar whether or not anyone is watching. So Business Central support is not optional insurance. It is part of how the service is meant to run.
This article sets out what Microsoft’s own model expects after go-live, the calendar you are signed up to, and the lines a support contract has to cover so that month-end is not the moment you find the gaps.
Who supports Business Central, according to Microsoft
Microsoft’s support model for Business Central online runs in a fixed order. Users go to the customer’s internal administrator. The internal administrator escalates to the reselling partner. The partner, working as a delegated administrator, investigates, and only if the partner cannot find a solution does it request support from Microsoft.
Three details in that model matter more than they look:
- The partner needs set-up to help at all. Access runs through an active granular delegated admin relationship, or GDAP: you accept a set of Microsoft Entra roles, and the partner assigns its own security groups to them. For Business Central the least-privileged role that does the job is Dynamics 365 Business Central Administrator. Microsoft’s support page still describes this as Admin agent or Helpdesk agent with delegated administration privileges, which is the older model it replaced.
- Your users find the partner through the product. The Help and Support page shows the partner’s support contact details, but only if the partner has provided them.
- Ending the relationship has steps. When a partner relationship ends, settings such as the support contact details and the notification recipients have to be removed and replaced.
The partner’s toolkit is specific, too. Working as delegated administrator, it can create a sandbox environment from production data to reproduce a problem, and analyse telemetry in the admin center to see what actually failed. A partner without delegated access is guessing from screenshots.
The consequence is simple. If your implementation partner walked away at go-live, you do not have a first line of support. You have an escalation path with a missing step.
The failure we find most often
When an estate comes to us for handover or emergency support, fewer than a third of the delegated admin arrangements we find are actually working. Those estates are self-selected, because they arrive when something has already gone wrong, but the cause is consistent enough to be worth checking in yours.
Most of it is a piece of Microsoft history. When Microsoft retired the old delegated admin model, it converted existing partner relationships automatically: it created a GDAP relationship carrying a set of default roles and assigned those roles to the partner’s Admin agent and Helpdesk agent groups. That worked for Microsoft 365. It did not work for Business Central, because not one of the default roles is Dynamics 365 Administrator or Dynamics 365 Business Central Administrator, and those are the only two roles that reach the Business Central administration centre. The result is a relationship that looks active in Partner Center and cannot open your environment.
Three things have to be true. None of them takes long to check.
- A live relationship carrying a role that actually reaches Business Central. Approved, still in term, and it cannot be permanent: two years at most, one year for anything created by that automatic conversion. A request your side never approved expires after 90 days.
- A security group in the partner’s tenant assigned to that role, with the people who help you in it. A role that is in the relationship but mapped to no group, or to a group your consultant is not a member of, produces exactly the symptom above.
- Partner access switched on for the environment. This one is yours, not theirs. Internal global administrators decide whether delegated administrators can sign in at all, and can restrict access to named partner tenants.
The update calendar you signed up to
Business Central online updates on a published cycle:
| Update | When | What it means for you |
| Major | Every April and October | New features and platform changes; extensions must be compatible |
| Minor | Every month without a major release | Improvements and fixes |
| Critical fix | As soon as it passes testing | Applied without waiting for the calendar |
For each major update, the update period lasts five calendar months from general availability, and administrators can reschedule it to any date inside that period. A scheduled update that fails is automatically rescheduled seven days later. Updates run inside each environment’s update window, by default 8:00 PM to 6:00 AM local time and never shorter than six hours, and Microsoft recommends scheduling an update for a day when the environment can be unavailable until that window ends.
Minor updates work differently, and the difference is where people get caught. They have no update period of their own: you schedule them inside the current major version’s five-month window, and if you do nothing, Microsoft schedules the next one itself, at least seven days out, targeting the latest available version. They still run automatically inside your update window. That is how a routine monthly update lands over a weekend without anybody deciding that it should.
Two things follow for support. First, every major update is a regression event for your extensions and any AppSource apps, and preview versions are available to sandbox environments before release precisely so that someone can test them. Second, the rescheduling freedom only helps if somebody uses it.
Month-end is where support earns its fee
Roughly half of the urgent calls we take across the Business Central estates we support land in the five business days spanning the last two of one month and the first three of the next, a window that is under a quarter of the working month. The reason is not that more breaks then. It is that the tolerance disappears. Mid-month, a posting warning is something people work around; at close, a foreign-exchange adjustment, an inventory costing run or a failed batch posting stops the books.
Put that together with the update calendar and the rule falls out: never let an update land in the days before close, major or minor.
The five-month update period gives you room to do that, but only if the date is chosen deliberately. The failed-update retry makes it sharper, because an update that fails a week before close is rescheduled seven days later, which is now close day.
A support arrangement worth paying for owns that calendar: it tests the release in a sandbox, picks the date around your close, sets the update window around your business hours, and watches the notifications.
What that looks like when nobody owns it
A multi-entity UK wholesale distributor had never touched its update settings, so Business Central did exactly what it does by default. Microsoft picked the date, and a routine monthly service update ran overnight in the standard window, into the weekend before close.
The bank feed came from a third-party integration, and it had cleared Microsoft’s automated pre-update validation. That validation checks that an extension still compiles and that its dependencies are still compatible with the incoming version. It does not run the extension, and it does not call the external services the extension depends on. So the break appeared at runtime, on the live connection to the bank’s aggregator, and the integration had no handling for the response it got back. It surfaced as a posting failure rather than as a readable error.
Nobody found out until Monday, which was day one of close. The notification recipients list in the administration centre was empty: the original partner had put its own mailbox there during the project and removed it at handover without adding anyone on the client side. Every email Microsoft sends when an update is scheduled had been going nowhere for months.
Restore was on the table, and it would have produced a readable copy of Friday’s data. It did not help, for a reason worth understanding before you need it. A restore lands as a separate environment rather than undoing anything in place, and by Monday the upgraded environment was already carrying the week’s dispatches, pickings and sales orders. Going back would have meant replaying all of it across several entities. Finance reconciled bank statements by hand in Excel for three days while support decoupled the extension.
Three of the four failures there were configuration, not software: no chosen update date, no notification recipients, no sandbox test. The fourth, an integration that only breaks when it runs, is the one telemetry is for. Business Central emits an event naming the extension, its publisher and the endpoint when an outbound call or its certificate fails, so an estate with telemetry switched on finds the culprit in minutes rather than by elimination.
Restore is not backup
Business Central online is protected by automated backups, and administrators can restore an environment to an earlier point. The limits are what support has to plan around:
- It is a new environment, not a rollback. You give a point in time and a name, and the restore arrives as a separate environment. The original keeps running untouched, which is useful for looking data up, but nothing is undone in place, and everything posted since has to be dealt with deliberately. If the restored copy needs the original name, the original has to be renamed first.
- 28 days back, and no further.
- Ten restores per environment per calendar month.
- Same Azure region and localisation as the original.
- The version at that time. The environment comes back on the version it was running then.
- Development extensions do not come back in a restored sandbox.
- Only people with the D365 BACKUP/RESTORE permission set can do it, alongside the delegated partner and internal administrators.
That first limit is the one that surprises people under pressure. Because the restore arrives alongside the running environment rather than replacing it, going back to it means giving up everything posted since, which on a busy estate is a day of dispatches and orders rather than a rounding error.
A mistake discovered at quarter-end, more than 28 days after it happened, cannot be undone by restore. That is a data-correction job, and it is exactly the kind of work that needs someone who already knows your configuration.
What a Business Central support contract must cover
Pulling Microsoft’s model and calendar together, these are the lines we would expect in any contract, and the questions to ask if they are missing.
| Line | Why it has to be there | Question to ask |
| Named first-line support with delegated admin set up | Microsoft’s model routes through the partner | Do we have an active GDAP relationship with you today, and which roles did we approve? |
| Support contact details in Help and Support | Users find support through the product | What do our users see when they open Help and Support? |
| Major update testing in a preview sandbox | Every April and October is a regression event | Who tests our extensions before each major release? |
| Update scheduling around close | Five-month window, seven-day retry | Who picks our update dates, and how do they know our close? |
| Telemetry and monitoring | Issues are diagnosed from telemetry and sandboxes | Is telemetry switched on, and who looks at it? |
| Restore runbook and permissions | 28 days, ten a month, specific permissions | Who can restore, and what is the process? |
| Data correction and reporting fixes | Restore cannot fix old mistakes | How are data corrections scoped and priced? |
Our position: fixed monthly support, scoped to the calendar
In our view the calendar work has to sit inside the fee rather than be drawn down from a bank of hours. Whether that fee is per user or a flat monthly retainer matters far less than whether testing the next release is somebody’s standing job.
An hours bank pays for reaction. The work that prevents month-end failures, testing each release, choosing update dates, watching telemetry, is proactive, and nobody spends banked hours on a release that has not broken yet. By the time they do, the hours are going on emergency work at the worst moment in the month. A fixed service makes that work somebody’s job.
The composition of the work is what settles the argument. Even in a stable estate, close to half of the support escalations we handle are not how-do-I questions. They trace to an AL extension, an AppSource app, or a Microsoft platform release. User questions fall away as people learn the system. The platform-driven work does not, because the calendar keeps producing it, so maintenance becomes a larger share of your support over the first year whatever the ticket count does.
This is also why contractual hypercare and operational settling are not the same thing. Thirty days of hypercare covers the first close and the initial shock, which is what it is designed for. Ticket composition takes about a quarter to settle: month one is user shock, month two is the first close the team runs on its own, month three is the steady state. The gap between the two is exactly where support arrangements tend to be thinnest.
To be fair to the other model, an hours bank is defensible on a stable single-entity estate with no per-tenant extensions and no ISV apps. Very few estates look like that, and the ones that do rarely stay that way. This is the same argument we make about managed services and projects more broadly: a project delivers the system, and something has to hold it afterwards.
Veratas runs Business Central managed support as a dedicated application service: incident management under an agreed SLA, Microsoft wave release assessment and regression testing, performance monitoring, and a monthly health report, scoped and quoted against your estate. It sits alongside our wider managed services for the Microsoft 365 and Azure side of the same environment. If you are still choosing an implementation partner, our fixed-fee Business Central implementation from $6,000 is scoped so that what happens after go-live is part of the conversation from the start. If you are still picking the partner rather than the support model, what to check in a quote comes first.
Where to start
Check four things this week:
- Open Help and Support in Business Central and see whose details your users are given.
- Check the admin center for your next major update date and your update window.
- Ask who tested your extensions against the last April or October release.
- Find out who can restore, and whether they know the 28-day limit.
If the answer to any of these is a pause, talk to our team. Business Central support is easier to set up before month-end than during it.
Frequently asked questions
Who provides support for Business Central online? The reselling partner is the first line. Users go to the internal administrator, who escalates to the partner, and the partner requests support from Microsoft if it cannot find a solution.
How often is Business Central updated? Major updates arrive every April and October, minor updates in every month that has no major release, and critical fixes as soon as they pass testing. Each major update has a five-month update period.
Can we delay a Business Central update? Within the five-month update period for each major release, administrators can reschedule the update to any date. A failed scheduled update is automatically rescheduled seven days later.
How far back can a Business Central environment be restored? Up to 28 days, and no more than ten times per environment per calendar month, within the same Azure region and localisation, to the version it was running at the time.
What should a Business Central support contract include? Named first-line support with delegated admin set up, major update testing in a preview sandbox, update scheduling around your close, telemetry monitoring, a restore runbook, and a defined route for data corrections.
Do minor updates need managing too, or only the April and October releases? Both. A minor update has no update period of its own, and if nobody schedules it Microsoft schedules it for you, at least seven days out, to run automatically inside your update window. A routine monthly update landing over a weekend is a common way for an integration failure to be discovered on the Monday.
How do we check our partner actually has delegated admin access? Three things have to be true: an approved GDAP relationship still in term that includes Dynamics 365 Administrator or, better, Dynamics 365 Business Central Administrator; a security group in the partner tenant assigned to that role, containing the people who support you; and partner access switched on for the environment. A relationship can look active in Partner Center while carrying no role that reaches Business Central.
What happens if our Business Central partner relationship ends? You lose the first line of Microsoft’s support model until a new partner is in place. The outgoing partner’s support contact details and notification settings should be removed and replaced.
Operations head with 20 years of experience delivering business intelligence, ERP and AI programmes across healthcare, finance and manufacturing. Focus areas include Power Platform adoption and governance, delivery models, and managed services.