1. Introduction
While updates are part of day-to-day operations—patch versions are released weekly in the first few months after a new major version is released, and monthly thereafter—upgrades of the edition are much less frequent. These are usually accompanied by budget approvals that either make the switch from Checkmk Community to a commercial edition possible in the first place or allow users to take advantage of the broader feature set of Checkmk Ultimate compared to Checkmk Pro in the future.
However the reverse action is sometimes necessary as well: For example, the Checkmk Ultimate running in the home lab may be reaching the service limit under the license state "Free" and require a switch to Checkmk Community in order to continue using Checkmk for free. Or new management may be cutting budgets. For this purpose, Checkmk also supports downgrades, which of course require a bit more preparation and follow-up work.
 |
This article covers the upgrade and the downgrade of a Checkmk edition—that is, switching to an edition with a different feature set, such as from Checkmk Community to one of the commercial editions or back.
An update of the Checkmk version and using the |
2. Preparations
Edition upgrades can be combined with updates to the Checkmk major version—for example, switching from Checkmk Community 2.4.0p33 to Checkmk Pro 2.5.0p8.
However, we recommend performing an upgrade only with the same Checkmk version, i.e., with identical major and patch versions.
In practice, this means that you should update your site to the latest available patch version of the edition you have been using before proceeding with the upgrade.
This update, at the very latest, is your opportunity to familiarize yourself with the omd command.
During an upgrade, the license state is reset. This also applies if, for organizational reasons, you initially ran Checkmk Pro with a license for Checkmk Ultimate, for example. Ideally, you should therefore have the licensing data on hand so you can enter it immediately after the upgrade.
3. Performing the upgrade
As with the update, the upgrade essentially consists of two steps:
First, use the Linux distribution’s package manager to install the Checkmk package for the target edition.
Next, for the site receiving the upgrade perform the activation of the new Checkmk edition using
omd update.
3.1. Installing the target edition
For an upgrade, the first step is also the installation of the desired new Checkmk version. This is done exactly as in the initial installation. In the following example, a package for Ubuntu 24.04 (Noble Numbat) is being installed:
You can view the list of installed Checkmk versions at any time using the omd versions command:
For details on the omd versions command, see the article on Updates.
3.2. Performing the site upgrade
The actual upgrade is performed using the omd command:
In the dialog box that appears, omd does not distinguish between an update and an upgrade.
The mechanisms working in the background are the same.
┌──────────────────────────────────────────────────┐ │ You are going to update the site mysite from │ │ version 2.5.0p4.community to version │ │ 2.5.0p4.ultimate. This will include updating │ │ all of your configuration files and merging │ │ changes in the default files with changes made │ │ by you. In case of conflicts your help will be │ │ needed. │ ├──────────────────────────────────────────────────┤ │ <Update!> < Abort > │ └──────────────────────────────────────────────────┘
4. Follow-ups
Once you have restarted your site, it will work as usual. However, it is a good idea to adjust a few settings to take advantage of the expanded functionality and improved performance. We explain these in the following sections in this article.
4.1. Upgrading Checkmk Community to a commercial edition
This section primarily covers an upgrade to 
Checkmk Pro.
You can also upgrade to Checkmk Ultimate in one step, but in this case, also refer to the notes in the following section.
Since the commercial editions have quite a few additional modules and features, there are a few things to keep in mind following any upgrade. The crucial point is that when creating new sites in Checkmk Community or one of the commercial editions, different default settings are set.
Nagios vs. the CMC
Since Checkmk Community only supports Nagios as its core, this is the default setting for sites created with Checkmk Community.
This setup will be preserved when upgrading to Checkmk Pro.
This means that after an upgrade you will initially continue to run with Nagios as the core.
A migration to the CMC is done with omd config and is described in its own article Migration to the CMC.
The RRD format
The commercial editions support an alternative format for storing historical measurement data, which generates significantly less disk I/O. This format is automatically preset for new commercial edition sites. Again, Checkmk Community sites are not automatically converted during an upgrade. How to switch the data formats is described in a separate section in the article on measured values and graphing.
Further differences
To take full advantage of Checkmk Pro, refer to the overview of differences between Checkmk Community and Checkmk Pro.
4.2. Upgrading Checkmk Pro to Checkmk Ultimate
When it comes to the monitoring core and the notification system, there are no differences between Checkmk Pro and Checkmk Ultimate. Depending on the focus of the deployment, you will often use the larger feature set only when adding new hosts. In some places, however, it is still advisable to review the existing settings.
For a complete overview of the additional functionality, see the article on Checkmk Ultimate.
Check plug-ins for cloud services
When you monitor Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP), the services in existing hosts reserved for Checkmk Ultimate will initially not be enabled. You can enable these services in the XYZ services to monitor rule (where XYZ is the name of the cloud platform). Then perform a service discovery on these hosts to find the services that will now be available.
Agent Controller in push mode
With the ability to directly monitor hosts that can reach the Checkmk server but are not accessible from it, the need for homegrown solutions with data source programs is eliminated in many cases. You can switch these hosts to push mode to enable a direct monitoring.
5. Upgrades in distributed environments
Note that in distributed environments, the version update must always be performed first before the edition upgrade can follow. A different sequence or a crossgrade (update of the version and upgrade of the edition in a single action) is not supported. As a general procedure, we recommend the offline upgrade, where you can jump from any lower edition to any higher edition.
In all upgrade scenarios except those targeting Checkmk Ultimate with Multi-Tenancy, mixed operation with different editions is possible if the following conditions are met:
The central site runs on an edition with a broader feature set than the remote sites.
The remote sites are integrated without configuration replication; that is, access is read-only.
5.1. Offline upgrade
As mixing editions is only possible in a few combinations, we generally recommend upgrading the edition offline. To do this, proceed as follows:
Stop all sites.
Perform the upgrade of the central site.
If it is desired (and an abundance of notifications is not a problem), the central site can be restarted immediately.
Now it’s time to upgrade the remote sites. You can do this in parallel and restart the remote sites immediately following their upgrading.
Of course, you can wait until all sites have been upgraded before restarting them, which will somewhat reduce the number of notifications generated.
5.2. Online upgrade
Checkmk allows for mixed operation between a central site with a broader range of features, and remote sites with a more limited set of features. For the upgrade, this means that the central site receives the upgrade first. During mixed operation, the configuration should not be transferred from the central site to remote sites that have not yet received the upgrade. Therefore, we recommend disabling configuration changes on the central site via Setup > General > Read only mode for the duration of mixed operation. Theoretically, such mixed operations can last indefinitely—in practice, however, configuration changes will become necessary after some time, requiring uniform editions across all sites.
This results in the following processing sequence for the upgrade:
Perform the upgrade of the central site.
Enter the licensing data and submit it as described in the article on licensing. The services provided by all remote sites are treated equally when calculating the subscription, meaning that during mixed operations, services from Checkmk Community remote sites will already be billed as Checkmk Pro or Checkmk Ultimate.
Update the remote sites one by one.
If you have not globally disabled configuration transfer, but instead separately for each remote site, you can re-enable configuration transfer for each remote site that has received the upgrade.
In distributed monitoring without a central setup, the remote sites must also be licensed immediately after the upgrade.
After upgrading all sites, you can enable the specific features of the new edition.
Remote sites actually discard settings that they 'cannot do anything with'. This does not break anything, but it can mess things up. Let’s say you activate a Checkmk Pro specific setting—for example regular scheduled downtimes--before all remote sites have received the upgrade. In this case, Checkmk Community sites will discard the setting, which means that it will not be available even after the upgrade. The setting will only be available once it has been changed again after the upgrade.
If it is impossible not to synchronize the configuration during the upgrade, check the consistency of Checkmk Pro specific settings after the complete upgrade.
6. Downgrades
Downgrades between editions are also supported. A downgrade is a more complex and therefore more time-consuming process, as some features may not work in the target edition and must be manually disabled and replaced with an alternative that may be less efficient or less user-friendly.
Be sure to carefully read the following to find out what needs to be done before proceeding with a downgrade.
Downgrades other than those described below are not intended and are not supported by us; for example, a downgrade from Checkmk Ultimate with Multi-Tenancy. Instead, we recommend starting with a fresh site in such cases.
6.1. Downgrading Checkmk Ultimate to Checkmk Pro
In preparation for the downgrade from Checkmk Ultimate to Checkmk Pro, you must make at least the following changes:
Set hosts that operate in push mode to pull mode. Otherwise Checkmk will not receive monitoring data from these hosts, and the hosts will usually become stale.
Reconfigure the agent packages for folders to stop auto-registration. Then re-bake the agent packages.
Furthermore, some cloud services and dashboards will no longer be available. As a result, you will need to clean up vanished services.
An overview of the differences between Checkmk Ultimate and Checkmk Pro is provided by the article on Checkmk Ultimate.
6.2. Downgrading Checkmk Pro to Checkmk Community
In preparation for downgrading from Checkmk Pro to Checkmk Community, you will need to make at least the following changes:
Change the RRD database format with the Configuration of RRD databases of hosts rule to Multiple RRDs per host/service. Besides slight performance disadvantages, it should be noted here that conversion of existing data is not included, so historical monitoring data will no longer be visible.
Switch the monitoring core from CMC to Nagios—in the first place this change is likely to result in performance disadvantages.
In addition, some dashboards, graph settings, notification plug-ins and special agents are no longer available. With the Checkmk Pro article you can determine how much Checkmk Pro functionality will be lost in the event of a downgrade to Checkmk Community and where you may need to make further adjustments.
6.3. Downgrade in distributed environments
The downgrade scenarios presented in the two previous sections can also be carried out in distributed environments. Note that in distributed environments, the version update must always be performed first before the edition downgrade can follow. A different sequence or a crossgrade (update of the version and downgrade of the edition in a single action) is not supported.
There is no downgrade scenario in which Checkmk supports a mixed operation between differing editions. For this reason, we strongly recommend that you perform the edition downgrade offline. To do this, proceed as follows:
Stop all sites.
Perform the downgrade of the central site.
If it is desired (and an abundance of notifications is not a problem), the central site can be restarted immediately.
Now it’s time to downgrade the remote sites. You can do this in parallel and restart the remote sites immediately following their downgrading.
Of course, you can wait until all sites have been downgraded before restarting them, which will somewhat reduce the number of notifications generated.
6.4. Performing the downgrade
The actual downgrade must—just like an update or upgrade—be performed using the omd update command.
For details, see the article on Updates.
For example, if you want to downgrade from Checkmk Ultimate to Checkmk Pro, Checkmk will prompt you to confirm that this is indeed your intention:
┌─────────────────────────────┐ │ You are updating from │ │ Ultimate to Pro. Is this │ │ intended? │ ├─────────────────────────────┤ │ < yes > < no > │ └─────────────────────────────┘
As soon as you confirm this prompt with yes, the downgrade will begin.