Business Central On-Premises: Checking Where Your Version Sits
Business Central on-premises follows the Modern Lifecycle Policy, and each release wave has a published end-of-servicing date. Several recent versions have already passed theirs. The first step is establishing which version an organisation is actually running.
Organisations running Business Central on-premises — or an older Dynamics NAV installation — often discover the lifecycle question only when something needs support. It is a schedule that can be checked in advance.
How the policy works
Microsoft's lifecycle page for Business Central on-premises records that the product follows the Modern Lifecycle Policy, with an end-of-servicing date published against each release wave version.
Microsoft describes what end of support means in general terms: upon retirement or end of support there are "no new security updates, non-security updates, free or paid assisted support options or online technical content updates."
That is the substance of the decision. It is not that the software stops working — it is that it stops receiving updates, including security updates, and assisted support is no longer available.
Published dates worth checking against your version
From Microsoft's end-of-support listings:
- Version 23.x (2023 release wave 2) — ended servicing 2 April 2025
- Version 24.x (2024 release wave 1) — ended servicing 7 October 2025
- Version 25.x (2024 release wave 2) — ended servicing 4 April 2026
- Version 26.x (2025 release wave 1) — ends servicing 13 October 2026
Two observations follow. The cadence is roughly six-monthly, in April and October, so a version is supported for a defined and fairly short window. And several of these dates have already passed — an organisation that has not upgraded in two years is likely running an unserviced version now.
These dates are as published by Microsoft and are subject to change. Confirm the current position on Microsoft's own lifecycle pages rather than relying on this list.
Establish the actual version first
Before any decision, confirm what is running. That means the Business Central or NAV version and build, whether any extensions or customisations are version-dependent, and which integrations rely on the current version's behaviour.
Organisations sometimes assume they are current because a recent project touched the system. Confirm from the environment itself, not from project memory.
The decision is upgrade, or move to the online service
Once the version position is known, the realistic options are to upgrade the on-premises deployment to a serviced version, or to move to Business Central online, where Microsoft manages the update cadence.
Neither is automatically correct. Factors that legitimately point on-premises include specific data-residency requirements, deep integrations with local systems, or heavily customised code. Factors that point online include the ongoing effort of upgrade cycles, infrastructure cost, and access to features delivered only in the online service.
What should not drive the decision is the assumption that staying put is the lower-effort option. Remaining on an unserviced version transfers risk to the organisation rather than removing it.
Where customisation changes the calculation
The upgrade effort is usually dominated by customisation rather than by the platform. Older NAV installations in particular may carry code modifications that predate the extension model, and those need assessment before any timetable is credible.
A realistic scoping exercise identifies which customisations are still used, which have been superseded by standard functionality, and which must be rebuilt as extensions. That assessment often reduces the work — organisations frequently carry customisations nobody has used for years.
What to establish
- Confirm the exact version and build currently running.
- Check its end-of-servicing date against Microsoft's current lifecycle pages.
- Inventory customisations, extensions and integrations, and identify which are still genuinely used.
- Assess data-residency, integration and regulatory factors that bear on on-premises versus online.
- Where an upgrade is chosen, plan for the recurring cadence rather than treating it as one project.
- Confirm the licensing position for the target deployment before committing.
Where the migration decision itself is the question, that is addressed in more detail in the migration decision framework, and implementation scope is covered under SCSB's Business Central implementation service.
General-information limitation
This article is general information about Microsoft product lifecycle concepts, not technical, licensing or legal advice for a particular organisation. It does not determine which version an organisation is running, whether an upgrade is required, or what any deployment decision should be. Lifecycle dates and policies are set by Microsoft and change over time. Confirm the current position against Microsoft's own published lifecycle material.
To discuss your requirements, contact SCSB.
Microsoft product references source checked: 25 July 2026.
Microsoft, Dynamics 365 Business Central and Dynamics NAV are trademarks of the Microsoft group of companies.