Dynamics 365 Business Central – Business Central Versions
Business Central is a business management solution for small and mid-sized organizations that automates and streamlines business processes and helps you manage your business. Highly adaptable and rich with features, Business Central enables companies to manage their business, including finance, manufacturing, sales, shipping, project management, services, and more. Companies can easily add functionality that is relevant to the region of operation, and that is customized to support even highly specialized industries.
Today we are going to focus on Business Central Versions and meaning.
1. Version numbers in Business Central
Business Central online and on-premises consists of different components that must work together. If you are an end-user, this doesn’t matter in the course of your normal working day. But if you are an administrator, knowing the version numbers is important for troubleshooting, development, and on-premises upgrade scenarios.
You can use the information about which version the tenant is on to help you troubleshoot an issue that a user has reported, for example. This information is listed in the Troubleshooting section of the Help and Support page in Business Central in the following format:
VERSION NUMBERS IN BUSINESS CENTRAL |
||
| Version | Example | Description |
| Platform <major>.<minor>.<build>.<revision> |
18.0.12345.0 |
Specifies the full platform version, which includes client and server components. |
| Application <major>.<minor>.<build>.<revision> | 18.1.23456.0 | Specifies the full version number for the application, including the major version number and build number. |
In the Business Central administration centre, the version information is rendered slightly differently:
| Version | Example | Description |
| Platform <major>.<minor> | 18.1 | Specifies the major and minor version of the platform, which includes client and server components. |
| Application <major>.<minor>.<build>.<revision> | 18.1.23456.0 | Specifies the full version number for the application. |
The numbers are updated based on Microsoft’s builds. In the default version of Business Central online, platform and application have the same major version number but different build numbers. If you perform a technical upgrade of Business Central on-premises, then platform and application will have different versions.
The following list describes the meaning of each of the numbers in a full version number:
- major is the major version of Business Central
- 18 is the Business Central 2021 release wave 1 update in April 2021 and forward
- 17 is the Business Central 2020 release wave 2 update in October 2020 and forward
- 16 is the Business Central 2020 release wave 1 update in April 2020 and forward
- 15 is the Business Central 2019 release wave 2 update in October 2019 and forward
- 14 is the Business Central April 2019 release
- 13 is the Business Central October 2018 release
- 12 is the April 2018 launch of Business Central
- minor is the monthly update number, such as 0, 1, or 5.
- build is the five digit build number, such as 23456.
-
revision is set to 0 for the original release and can remain at 0. However, if the tenant is patched with a hotfix, then that build number can be applied.
In other words, if you see a version number such as 18.1.23456.26323, then it means major version 18, update number 1, build number 23456, and hotfix number 26323.
The same version numbers are used to identify versions in Business Central on-premises, including when you deploy containers on Docker.
2. Upgrading to Dynamics 365 Business Central 2021 Release Wave 1
Business Central 2021 release wave 1 (version 18) is the fourth major release that is fully AL-based. Business Central 2019 release wave 2 (version 15) marked the release in which C/AL was replaced by AL. The classic development environment, known as C/SIDE, was deprecated. From an application perspective, Business Central is now extension-based only. The Business Central base application is delivered as an AL extension. Also, application functionality that isn’t related to the business logic has been moved into separate modules. These modules are combined into an extension known as the System Application. This change will influence how you do the upgrade compared to earlier releases.
Upgrade path
Depending on your current version, a direct upgrade to version 18 isn’t always possible. You may have to first upgrade to an intermediate version. The following table describes the upgrade paths for supported versions:
Source version |
Path |
|
|
|
Direct to version 18 |
Your current version doesn’t have to be the latest update for the version. However, for intermediate versions, use to the latest available update.
Upgrade overview
When upgrading your Business Central Spring 2019 (version 14) solution to version 18, the goal is to move towards a full uptake of the Business Central base and system applications, as they are, and migrating code customizations to add-on extensions. There are different upgrade levels that you follow to get to this state, as illustrated in the following figure. We recommend that you refactor to the system application as a minimum.
Technical Upgrade
Although it’s recommended to refactor to the system application as a minimum, you can do a technical upgrade only. A technical upgrade changes the database so that it works on the latest Business Central platform. The conversion updates the system tables of the old database to the new schema (data structure). It provides you with the latest platform features and performance enhancements.
When upgrading from version 14, part of the technical upgrade process includes converting your customized base application from C/AL to AL.
New and changed features
There are several new and changed platform and application features available in Business Central 2021 release wave 1. These changes affect users, administrators, and developers. For an overview of these features, see Overview of Dynamics 365 Business Central 2021 release wave 1.
To take advantage of these features, you’ll have to do an application code upgrade, not just a technical (platform) upgrade.
Deprecated features
Before you upgrade, review the following articles to get an overview of features deprecated in this release:
From this article, use the links in the table of content to view deprecated features specific to local versions.
Technical Upgrade
For information about migrating an on-premises solution to online, see Migrate to Business Central Online from Business Central On-premises.
Upgrading Extensions
This article provides information about how to make a newer version of extension upgrade available on tenants. The first phase of the process is to develop the extension for upgrading. In this phase, you add code to upgrade data from the previous extension version. Once you have the upgrade code in place, you can publish and synchronize the new version, and the run the data upgrade.
Writing upgrade code
When you develop a new extension version, you must consider the data from the previous version. Determine the modifications that must be made to the data to make it compatible with the current version. For example, maybe the new version adds a new field that needs default values set for existing records, or the new version adds new tables that must be linked to existing records. To address this type of data handling, you must write upgrade code for the extension version. If there are no data changes between the extension versions, you don’t need to write upgrade code. All data that isn’t modified by upgrade code will automatically be available when the process completes.
You write upgrade logic in an upgrade codeUnit, which is a codeUnit whose SubType property is set to Upgrade. An upgrade codeUnit supports several system triggers on which you can add data upgrade code. These triggers are invoked when you run the data upgrade process on the new extension.
The upgrade codeUnit becomes an integral part of the extension and may be modified as needed for later versions. You can have more than one upgrade codeUnit. There’s a set order to the sequence of the upgrade triggers, but the execution order of the different codeUnits isn’t guaranteed. If you do use multiple upgrade units, make sure that they can run independently of each other.
Upgrade triggers
The following table describes the upgrade triggers and lists them in the order in which they’re invoked.
Trigger |
Description |
Fails the upgrade on error |
| OnCheckPreconditionsPerCompany() and OnCheckPreconditionsPerDatabase() | Used to check that certain requirements are met before the upgrade can be run. | Yes |
| OnUpgradePerCompany() and OnUpgradePerDatabase() | Used to do the actual upgrade. | Yes |
| OnValidateUpgradePerCompany() and OnValidateUpgradePerDatabase() | Used to check that the upgrade was successful. | Yes |
PerCompany triggers are run once for each company in the database, where each trigger is executed within its own system session for the company.
PerDatabase triggers are run once in the entire upgrade process, in a single system session that doesn’t open any company.