Business Central on-prem: the servicing clock nobody reads

If your finance system runs on Microsoft Dynamics 365 Business Central on-premises, there is a date on a Microsoft lifecycle page that almost nobody who owns that estate has looked at. The version you are running has an end of servicing date, and for the current wave it is October 13, 2026.

That is less than two months from this writing. It is also the second such date this year: the wave before it went out of servicing on April 4, 2026 — quietly, with no announcement, no countdown, and nothing on the system to indicate it had happened.

This post is about the assumption underneath that. On-premises does not mean "supported until we decide to upgrade." It means you control the timing of the upgrade, not whether the version you are sitting on is still being maintained. Those are very different things, and finance teams inherit the first belief far more often than the second fact.

The dates, exactly as Microsoft prints them

Microsoft's lifecycle page for Dynamics 365 Business Central on-premises is a short table. Re-read on August 19, 2026, the rows that matter render like this:

• 2025 release wave 1, version 26.x — starts 4/1/2025 8:00:00 AM, end of servicing 10/14/2026 6:59:59 AM
• Version 27.x — end of servicing 4/6/2027 8:00:00 AM
• Version 28.x — end of servicing 10/13/2027 8:00:00 AM

And the row that has already fired: 2024 release wave 2, version 25.x, ended 4/4/2026. If that is the version in your production environment, you have been running an unserviced build since the spring.

Two things about the page itself are worth knowing. The policy is Modern, not Fixed — more on why that matters below. And Microsoft's own end-of-support roundup files this product under the category "End of Servicing" rather than "End of Support", which is a real distinction and not a euphemism: the product line is alive and shipping, it is the specific build you are running that stops being maintained.

Why "Modern Lifecycle" is the load-bearing word

Most people managing an on-premises estate have a mental model built from products on the Fixed Lifecycle Policy: a mainstream phase, then an extended phase where security updates continue for years, and sometimes a paid bridge beyond that. Windows Server and Exchange work that way. It is a generous, forgiving structure, and it has trained a generation of IT leads to assume there is always a cushion.

Modern Lifecycle has no such structure. There is a servicing window and there is what comes after it, which is nothing. No mainstream-versus-extended split, no security-only tail to plan around, no paid extension to buy while you catch up. The policy assumes you stay current; staying current is the support arrangement.

This is the same policy trap we wrote about on the ERP side in Dynamics GP retires end of 2029, where the absent extended-support phase is the detail that quietly moves a 2029 project two years earlier than people plan for. Same policy, different product, and here the window is measured in months rather than years.

What end of servicing actually costs you

Nothing visible happens on the day. That is the entire difficulty. There is no banner, no licence check, no degraded mode — the system on October 14 behaves exactly as it did on October 13, and month-end closes the same way it always has. The cost is not an event; it is a slope.

• Updates stop for that build. Fixes released after the date target serviced versions, not yours. Every month that passes widens the gap between the code you are running and the code that is being maintained.
• Your support posture changes. Running an unserviced version is a materially different conversation with a vendor, an auditor, or an insurer than running a current one — and it is a conversation you would rather not be having for the first time during an incident.
• The catch-up gets more expensive, not less. One wave behind is a routine upgrade. Three waves behind is a project with its own testing plan. Waiting does not preserve the option; it prices it.
• It compounds silently across the rest of the estate. An ERP that is frozen because nobody wants to touch it starts constraining everything that integrates with it — reporting, identity, the tenant work around it. The ERP stops being the thing you upgrade and becomes the reason you cannot upgrade anything else.

What a twice-yearly upgrade discipline actually involves

If the answer is "stay on-premises", then the six-month cadence is not a risk to manage — it is a standing operational commitment, and it needs to be resourced like one. In practice that means four things exist and have an owner:

1. A known current version. Not the version you bought, not the version in the project document — the one running in production today, written down somewhere a finance director can find it.
2. A non-production environment to upgrade first. Without one, every upgrade is performed live on the system that closes your books, which is why so many on-premises estates stop upgrading altogether.
3. A regression pass over customizations, integrations and reports. This is where the real work sits. The upgrade itself is mechanical; what breaks is the surrounding surface that was built against a particular version and never re-tested.
4. A calendar with a named owner. Two upgrade windows a year, scheduled around your close cycle rather than around whoever happens to be free. If this lives in one person's head, it lapses the first time that person is busy — which is the ordinary way an estate ends up three waves behind.

That is a legitimate operating model. It is not, however, a free one, and it is usually costed at zero because the lapse it prevents has never produced a visible failure.

The honest decision: cadence, or the service

There are two defensible answers here and we are not going to pretend one of them is obviously right.

Stay on-premises and adopt the twice-yearly discipline above. You keep control of the data location, the timing of every change, and the depth of customization you are able to run. You accept a recurring upgrade project, a test environment, and an owner — permanently, not once.

Move to the online service and the upgrade project disappears, because updating becomes continuous rather than episodic. What you give up is control of timing: changes arrive on the vendor's calendar rather than yours, and customizations and integrations have to live inside what the service supports. For some estates that constraint is trivial. For others it is the whole reason they are on-premises in the first place.

The wider Dynamics cluster around January 2027

Business Central is not the only thing on the clock. Microsoft's end of support in 2027 roundup carries two Dynamics entries worth putting on the same page as your Business Central dates:

• Dynamics NAV 2017 — end of support 1/11/2027, under the Fixed Lifecycle Policy.
• Dynamics 365 for Customer Engagement Apps, version 9.x (on-premises update) — moves from Mainstream Support to Extended Support on 1/12/2027. That is a phase change, not an end date: Extended Support is the security-updates-only period.

And a set that is frequently written up as upcoming when it is not. These have already passed: Dynamics CRM 2016 on 1/13/2026, Dynamics NAV 2016 and Dynamics C5 2016 on 4/14/2026, and Dynamics GP 2016 and GP 2016 R2 on 7/14/2026. If any of those are still in production, you are not planning for a deadline — you are past one, and the remediation conversation is a different one.

The Customer Engagement entry is the one most likely to be sitting quietly in a mid-market tenant alongside a Business Central estate. If an on-premises Dynamics CRM install is in the picture, its destination is the customer engagement apps on Dataverse, and that is the work our Dynamics 365 implementation practice does.

How to sequence this

1. Establish the version actually running in production. Everything else is guesswork until this is written down.
2. Put it against the lifecycle table — reading each row's timestamp individually, per the warning above.
3. Decide the model before the project. Twice-yearly discipline on-premises, or the online service. That is a business decision, not an IT one.
4. If you are staying, fund the discipline. Test environment, regression scope, named owner, two windows a year on the calendar.
5. Inventory what integrates with the ERP. That list is the real cost of every upgrade, whichever model you choose.
6. Check the rest of the Dynamics estate for the January 2027 entries above, and for anything on the already-passed list.

Sequencing the identity and tenant work around an ERP move is its own exercise — the same shape as the planning in our Microsoft 365 migration work, and scoped the way we describe in our methodology: the decision and the design first, the execution after.

Sources

• Microsoft Lifecycle — Dynamics 365 Business Central on-premises (Modern Policy)
• Microsoft Lifecycle — Products end of support in 2027

The 30-second version

Business Central on-premises runs under the Modern Lifecycle Policy, and a release wave drops out of servicing roughly every six months. Version 25.x ended on April 4, 2026. Version 26.x ends at the end of October 13, 2026. There is no extended-support phase behind either. Nothing breaks on the day, which is exactly why estates drift several waves past the line without anyone noticing. Read each row's timestamp individually — the table encodes 26.x as end-of-previous-day and 27.x and 28.x literally — then make the real decision: fund a twice-yearly upgrade discipline on-premises, or move to the service and trade timing control for continuous updates. Either answer is defensible. Drifting is not an answer.

Pro IT NW is an independent Microsoft consultancy in Seattle, working USA-wide. Senior-led, fixed-fee, labor-only — we do not resell Microsoft licensing and take no commission on it, so nothing in the advice above depends on what you buy. If a Dynamics lifecycle date is on your board, our Dynamics 365 practice is where that conversation starts.