Migrate from PRTG to Checkmk

Migrate from PRTG to Checkmk: what moves cleanly and what does not

If a PRTG renewal, a licensing change or a data residency requirement is pushing you off PRTG, the good news is that the device list can be exported through the PRTG API, so you do not start from a blank inventory. What does not move cleanly is almost everything that encodes your alerting judgment: sensor configurations, thresholds, notification rules, maps and custom sensors. Plan to rebuild those in Checkmk rather than expecting a direct import. The practical split is that hosts and their addresses are mechanical to move, while the monitoring logic is a design task.

The work usually falls to a platform or monitoring engineer who can run the Checkmk server and write the export and bulk host creation scripts, working with a Windows owner who knows which servers matter and a network owner who knows which switches and firewalls are in scope. The Windows owner should confirm which PRTG sensors are business-critical, because service discovery in Checkmk will find far more services than anyone tracks in PRTG. The network owner should confirm SNMP community or credential details, since these are not included in a device list export and must be supplied again.

Effort and risk are driven by three things: how many devices and sensors you hold, how many thresholds were tuned by hand, and how many notification paths feed ticketing or on-call tools. Ask your team to inventory those three before scheduling anything, and check current Checkmk installation and edition requirements in the Checkmk setup guide against your target platform. Run both systems in parallel until alert behavior matches, and do not switch off PRTG until your renewal end date is confirmed with your vendor.

Which PRTG capabilities map to Checkmk, and which need rework

This table maps the main PRTG capabilities to their Checkmk equivalents and marks each as clean, needs rework or gap. Read the edition column first, because push-mode agents, automatic host registration and Synthetic Monitoring depend on which Checkmk edition you run.

PRTG capability	Checkmk equivalent	Status	Notes for the migration
Device list and host inventory	Hosts and host tags exported from PRTG and bulk-created in Checkmk	Needs rework	Map PRTG groups and device tags to Checkmk folders and host tags before import, and confirm the import method against current Checkmk documentation.
Sensors and channels	Checkmk services discovered per host	Needs rework	Each PRTG sensor type maps to one or more Checkmk check plugins. Sensor counts will not match service counts one to one.
Auto-discovery	Service discovery on each host	Clean	Checkmk discovery covers most standard Windows, Linux and SNMP services. Automatic host registration is an Ultimate feature.
Agents on Windows and Linux	Checkmk agent in pull mode on all editions	Clean	Pull-mode agents work on Community. Push-mode agents are an Ultimate feature, so plan agent rollout around your edition.
Thresholds and alert limits	Service parameters and check thresholds	Needs rework	Re-enter warning and critical levels per check, or set them through rules. Do not assume PRTG limits carry over unchanged.
Notifications and escalation	Notification rules and notification methods	Needs rework	Rebuild each PRTG notification template and trigger as a Checkmk rule and test it against a sample alert before cutover.
Maps and dashboards	Checkmk dashboards and views	Needs rework	Recreate maps and dashboards by hand. Confirm current dashboard and map equivalents against current Checkmk documentation.
Reporting and historic data	Checkmk reporting and graphs (Pro or Ultimate for advanced reporting)	Gap	PRTG history does not import into Checkmk. Keep an archived export and confirm reporting features against the editions page.
Synthetic and web transaction checks	Synthetic Monitoring add-on	Gap	Synthetic Monitoring is available only with Pro and Ultimate, so it is not part of Community.

What to export from PRTG and what to rebuild in Checkmk

PRTG holds two kinds of material that move differently. Device and sensor inventories can be pulled through its HTTP API and loaded into Checkmk, while alerting logic, maps, reports and integrations usually have to be recreated by hand. Treat each card below as a separate workstream with its own owner and acceptance check.

Device and sensor inventory

Pull the device list, group structure and sensor list through the PRTG HTTP API in XML, JSON or CSV. Each record carries the device name, address, parent group and sensor type, which is the input for bulk host creation in Checkmk. Check that every device has a unique name and a reachable address, because Checkmk host names and IP addresses drive discovery. Confirm the export covers all probe and group levels, since sensors inherited from parent groups do not always appear on the device row.

Historic data kept for reference

Historic sensor data usually stays in PRTG. Checkmk builds its own history from the point it starts polling, so older graphs and trend data are not moved as part of a standard host import. Export the historic series to CSV or JSON only where audits or capacity reviews need it, and store the files in a location the monitoring team controls. Ask the PRTG administrator how long the subscription keeps history before it becomes unavailable.

Notification templates and rules

PRTG notification templates for email, SMS and scripts do not map one to one to Checkmk notification rules. Document each PRTG trigger, its recipients and its escalation timing, then rebuild the equivalent rules in Checkmk using host and service filters. Confirm the rule order, because Checkmk evaluates notification rules in sequence and a broad early rule can suppress a narrow later one.

Custom sensors and scripts

Custom EXE/Script sensors and WMI or SQL sensors have no direct equivalent in Checkmk. Each script needs an assessment: some can be replaced by a bundled check plugin, some by a local check written for Checkmk, and some should be retired. Test each replacement against the same thresholds and output the PRTG sensor produced, and record who signs off that the new check measures the same thing.

Maps, dashboards and scheduled reports

PRTG maps and scheduled reports have to be recreated in Checkmk dashboards and reporting. Export the list of maps and report schedules from PRTG as an inventory, then decide which views operations teams use daily and which exist only for periodic reporting. Confirm recipients and delivery frequency with report consumers, since these are often the least documented items in a PRTG installation.

Ticketing and on-call integrations

Webhooks, ticket creation and on-call paging configured in PRTG must be rebuilt against the tools your teams use. Checkmk supports notification through scripts and plugins, so each integration needs a working test alert and a documented owner. Confirm the ticketing system and paging service endpoints, credentials and alert payload fields before cutover, and run both monitors in parallel until each integration has fired at least once in a controlled test.

Migration sequence from inventory to decommission

This sequence moves PRTG device monitoring to Checkmk in controlled stages, so each stage ends with a signed-off artifact before the next begins. The reader finishes with Checkmk alerting for the full estate and PRTG retired without a gap in coverage.

Export and reconcile the PRTG inventory
Pull the device and sensor lists from the PRTG HTTP API in XML, JSON or CSV, then reconcile them against your CMDB or asset register. The owner is the monitoring lead with input from the server and network teams. Done means a reconciled host list where every device has an owner, a address, an operating system or device type, and a note on whether its sensors map to Checkmk services, plus a list of PRTG-only items such as maps and custom sensors that must be rebuilt by hand.
Install a pilot site and select a pilot group
Choose one host group that is representative but low risk, such as a set of Linux servers in a single segment. Install Checkmk on a Linux package or Docker image, using Community for the pilot unless you already need a commercial feature. Confirm the edition's capabilities against the editions page before deciding, since push-mode agents and automatic host registration are Ultimate features. Done means a running site, the pilot hosts reachable from it, and a written note recording the edition chosen and why.
Bulk create hosts from the exported list
Generate a host import from the reconciled list for the pilot group only, and create the hosts in Checkmk with consistent folder placement, tags and IP addresses. Keep the PRTG device IDs in a host label or alias so each Checkmk host can be traced back to its source. Done means the pilot hosts exist in Checkmk with correct addresses, and a spot check of a sample against the PRTG record shows no mismatched names or addresses.
Run service discovery and tune rules
Run service discovery on the pilot hosts, then compare the discovered services with the sensors PRTG monitors on each device. Accept the services that match, remove noise such as interfaces or volumes that should not alert, and set thresholds through check parameters and rule sets instead of copying PRTG values one by one. Done means a documented rule set for the pilot group and a list of PRTG sensors with no Checkmk equivalent, each marked as covered, accepted as a gap, or moved to a custom check.
Run both tools in parallel and compare alerts
Keep PRTG alerting on the pilot hosts while Checkmk alerts into a test channel, and record every alert from both tools over the agreed observation period. Investigate each mismatch to find whether the cause is a threshold, a missing check, a notification delay or a false positive. Done means a signed-off alert comparison, reviewed by the service owners, that explains every difference between the two tools before any notification moves.
Expand the rollout and cut over notifications
Repeat the inventory, import, discovery and tuning steps for each remaining host group, starting with the lowest-risk groups. Move notification rules for each group from PRTG to Checkmk, then disable the PRTG notifications for that group only after the on-call team confirms they receive test alerts. Done means every in-scope host is monitored in Checkmk, its notifications are routed through Checkmk, and the change log records who approved each cutover.
Decommission PRTG after the subscription ends
Keep a read-only PRTG instance long enough to retain historic data for audit and trend needs, and export any history you need to keep before the subscription ends. Remove the PRTG probes and devices once the export is verified and no group still depends on it. Confirm the timing with your licensing contract and procurement team, since the end date is set by the agreement. Done means a verified archive of exported history, a closed change record for the PRTG shutdown, and a single monitoring system of record in Checkmk.

Running PRTG and Checkmk in parallel until alerts match

Keep PRTG as the alerting source of record while Checkmk monitors the same hosts in shadow mode, and do not switch notifications until the two systems agree over a period you have measured yourself. In practice this means Checkmk sends its notifications to a test contact or a dummy notification rule, while PRTG continues to page the on-call team. Export the PRTG device list through the API first so that both systems watch the same set of hosts, then compare the alert events from both tools side by side. Each PRTG sensor down, warning and recovery should have a matching Checkmk service state change within an agreed time window, and each mismatch should be logged with the host, the service and the cause.

Most differences fall into three groups: thresholds that were set by hand in PRTG but are defaults in Checkmk, services that Checkmk discovers and alerts on but PRTG never monitored, and PRTG sensors with no Checkmk equivalent such as some custom or vendor-specific checks. For each group, decide whether to copy the PRTG threshold into the Checkmk rule, accept the discovered service and disable its notifications, or build a custom check. Record the decision in a shared register so that the people who sign off the cutover can see why each difference remains. Confirm with your own team how long the parallel run should last. No fixed duration should be assumed: the right length depends on your alert volume, how often incidents recur, and whether your quietest weeks include the events that matter most. Measure the number of alerts per week from PRTG's history before you set the window.

Define the cutover decision in advance as a written checklist: the agreed mismatch count has been closed, the on-call rota has been briefed, and the rollback owner is named. At cutover, move the PRTG notification rules to a disabled state rather than deleting them, and keep PRTG polling for the agreed period so that the history stays available. The rollback path is to re-enable the PRTG notification rules and disable the Checkmk ones, which should take minutes if the rules were kept intact. Test that path before cutover, not during an incident. Confirm with the vendor and your own environment how long PRTG history is retained under your subscription, because that data sets how far back you can compare alerts after the switch.

How the move differs for Community, Pro and Ultimate starting points

Checkmk Community is free, open-source software built on the Nagios core, and the editions page describes it as suited to small infrastructures, easily scaled up to about 100 hosts. For a PRTG estate in that range, the migration is mostly manual work on your side: you create hosts from the PRTG device export, run service discovery per host and recreate thresholds and notifications by hand.

Host creation: Hosts are added from your exported device list, typically through the web interface or scripted with the Checkmk command line tools.
Service discovery: You run discovery on each host and review the services it proposes, because there is no automatic host registration in this edition.
Agents: Agents are installed and configured on each Windows or Linux server, since push-mode agents are an Ultimate feature.
Core: Community runs on the Nagios core, so it does not use the Checkmk Micro Core that the commercial editions create by default.
Cost: The license fee is zero, but staff time for host setup, rule writing and upkeep recurs.

Confirm the host count from your PRTG export before committing, because a count beyond about 100 hosts changes the edition decision.

What drives the cost and duration of the migration

This table lists the factors that change how much work a PRTG to Checkmk move takes and which costs are paid once versus every year. Read each row as a question to answer about your own estate before asking any partner or vendor for a quote. The main takeaway is that inventory accuracy and the PRTG export decide most of the effort, while the Checkmk edition decides the recurring spend.

Driver	Why it changes cost or effort	What to confirm or ask for
Hosts and services	Host count sets discovery, rule and validation work. Checkmk pricing for commercial editions is tied to services, so service count matters for recurring cost.	A host and service count per site from PRTG, plus a Checkmk service estimate for the target edition.
Windows agent versus agentless coverage	Agent-based hosts need agent rollout, certificate or registration handling and firewall changes. Agentless hosts depend on SNMP, WMI or API access that must be re-tested.	Split of hosts by agent, SNMP, WMI and API monitoring, and who owns the rollout on each server group.
Custom sensors and scripts	Each custom EXE/XML, script or WMI sensor must be mapped to a Checkmk check, a custom plugin or a retired check. This is usually the least predictable item.	A list of custom sensors with owner, purpose and whether the data is still used in any report or alert.
Thresholds and notification rules	Thresholds must be recreated per host group, and notification rules must match escalation paths. Complex PRTG notification templates take longer to translate.	Count of notification templates and escalation levels, and the number of thresholds that differ from defaults.
Stakeholders who sign off alerts	Each team that receives alerts needs review and sign-off during parallel running, which lengthens the test window more than the build itself.	Named approvers per service area and a sign-off process with a fixed review period.
State of the PRTG API export	Device, sensor and history exports through the PRTG HTTP API are scripted work. Gaps in the export, such as missing history or undocumented sensor settings, add manual rebuild effort.	Confirmation that device and sensor lists export cleanly, what history is kept, and which items must be rebuilt by hand.
One-time work: migration, testing and training	Inventory, rule mapping, bulk host creation, parallel running and staff training are paid once, typically to internal staff, a partner or both.	A fixed-scope written plan with deliverables, test criteria and training sessions named separately.
Recurring work: Checkmk subscription, hosting and staff time	Commercial editions add a recurring subscription. Community is free software but still needs servers, backups, upgrades and monitoring staff time every year.	Edition choice with the current Checkmk editions list price, server sizing, upgrade cadence and the named internal owner.

What usually goes wrong when moving from PRTG to Checkmk

Most failed PRTG to Checkmk migrations do not fail in the tool. They fail in the copy: discovery adds services nobody asked for, thresholds move without review, and alerts stop reaching the people who act on them. Each card below names one failure mode and the check that prevents it.

Discovery creates unwanted services

Checkmk's service discovery finds everything a host exposes, including interfaces, file systems and processes that PRTG never monitored. Each extra service becomes an alert source, and the noise often appears on the first day of the parallel run. Before you accept discovery results, export the PRTG sensor list for each device and compare it with the Checkmk service list. Use discovery rules and service filters to keep only the services you intended to monitor, and document every exclusion so the next reviewer knows it was deliberate.

Thresholds copied without review

PRTG sensor limits were often set per device during a past incident or tuned by hand over years. Copying those values into Checkmk carries forward settings that may no longer match the workload, and it can also hide a limit that was never set. Pull the PRTG warning and error limits for each sensor, mark which ones were deliberate, and confirm each with the owner of the system. Treat the first two weeks of Checkmk alerts as evidence for adjusting thresholds, not as proof they are correct.

Missed notification paths

PRTG notifications often reach people through email templates, SMS gateways, scripts or escalation triggers that were configured years ago and are no longer documented. Checkmk notification rules have to be rebuilt from scratch, so a path that existed only in PRTG can disappear without anyone noticing. Inventory every PRTG notification trigger and action, map each one to a Checkmk rule, and test each path with a controlled alert. Confirm that on-call staff, ticket integrations and maintenance windows behave the same way before cutover.

Duplicate alerts during the parallel run

Running PRTG and Checkmk side by side is useful for comparing results, but both systems will alert on the same outage if both reach the same channels. Engineers then receive two pages for one event and start ignoring the alerts. Route the Checkmk notifications to a test group or a separate channel during the parallel run, and record which system is authoritative for each host. Switch a host to Checkmk alerting only after its results match PRTG over an agreed period.

Host inventory drifts from PRTG

A device list exported through the PRTG API captures what PRTG knows at that moment, but teams keep adding and retiring hosts during the migration. Checkmk then ends up with hosts that were never migrated or with old devices still polling. Freeze the scope for the migration window, export the device list again just before cutover, and reconcile the two lists by hostname, IP address and owner. Assign one owner for each host so changes are made in one place.

PRTG expires before parity is reached

A PRTG subscription can end before every sensor, threshold and notification path has been verified in Checkmk, which leaves the estate without a monitoring record during the gap. Check the end date of your PRTG license now, and work backward from it to set the parity checkpoints. Export historic data and configuration while access is still active, and keep a read-only copy of the exports. Confirm the renewal or end date with Paessler and your procurement team, since the schedule depends on your own contract.

Questions buyers ask before moving from PRTG to Checkmk

How much effort does a PRTG to Checkmk migration take?

The effort depends mostly on how many devices and sensors you run, how many custom sensors and notification rules you have, and how much of your alerting logic lives in PRTG maps and dashboards that must be rebuilt by hand. Checkmk's service discovery can populate many hosts quickly once the host list exists, so the time-consuming part is usually reviewing thresholds, deciding which checks to keep and rebuilding notifications. No duration figure is supplied for this work, so ask any partner to state effort in writing against your own device count and sensor inventory before you commit.

Can our own team migrate from PRTG to Checkmk without outside help?

A team with Linux administration experience and a clear inventory of what PRTG monitors can run the migration itself, because Checkmk installs from standard Linux packages or Docker images and its discovery tooling does the bulk of host onboarding. Teams without recent Checkmk experience usually struggle with rule sets, check parameters and notification design, which are where most of the rework appears. Outside help is typically scoped as a fixed-scope engagement with agreed deliverables, which DeployOpen offers for planning, implementation and documentation, or as a retainer for ongoing support.

What skills does our staff need to run Checkmk after the move?

Your staff need Linux operations skills to maintain the server and updates, plus working knowledge of Checkmk concepts such as hosts, services, check parameters, rule sets and notification rules. Someone should own the monitoring configuration as code or documented rules so changes are repeatable. If you plan to use push-mode agents or automatic host registration, confirm first whether your edition includes them, because the setup guide lists those as Checkmk Ultimate features.

Is Checkmk Community enough to replace PRTG?

Checkmk Community is enough for smaller estates. The editions page describes it as free, open-source monitoring for small infrastructures, easily scalable up to about 100 hosts. If your PRTG deployment covers more hosts than that, or needs distributed monitoring, advanced reporting or 8x5 support, you should compare the commercial editions before you start. Check your current host count against that limit, because it determines the edition choice more than any other factor.

What does a commercial Checkmk edition add, and what does it cost?

The commercial editions add capabilities that Community does not include. According to the Checkmk editions page, Pro adds advanced analytics and reporting, automation, distributed monitoring and 8x5 support, and it is listed from 190 euros per month billed annually. Ultimate adds full-stack observability, multi-tenancy, advanced security compliance and automated mass rollouts, and it is listed from 275 euros per month billed annually. The Cloud edition is listed at 240 euros per month billed yearly and capped at 50,000 services. Confirm current pricing and any tax or support terms directly with Checkmk, because list prices change.

Does the commercial edition change which core runs the monitoring?

Yes. Checkmk's docs say the commercial editions create new sites with the Checkmk Micro Core by default, while Checkmk Community is built on the Nagios core. The commercial editions keep the Nagios core only as an optional core for migration. If your team plans to move between editions later, confirm the core and site behavior in the current documentation before you build your first site, because it shapes how sites are created and migrated.

How does the PRTG export timing relate to the subscription end?

Export your device list, sensor configuration and historical data while your PRTG subscription is still active, so you can reach the API and the data without disputes about access. Historical data is usually the item that takes longest to pull, so start that export early and keep the output in a store you control. Do not switch off PRTG until Checkmk alerts match what PRTG produced over a comparison period you agree in advance. Confirm your own subscription end date and renewal terms with Paessler, because those dates are specific to your contract.

Will the migration cost us anything beyond the Checkmk license?

Yes. The main recurring costs are the server or virtual machine that runs Checkmk, storage for monitoring history, backups, and the staff time spent maintaining configuration and responding to alerts. The one-time costs are planning, host onboarding, rebuilding notifications and maps, and validation. Ask any quote to separate these items, state who performs each task, and show what changes if your host count grows past the Community limit.

How DeployOpen scopes and runs a PRTG to Checkmk migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted platforms inside the client's own infrastructure, and a PRTG to Checkmk migration follows the same pattern. Most engagements are fixed-scope: the device inventory to be moved, the Checkmk edition and hosting model, the notification paths, the cutover window and the acceptance tests are agreed in writing before any work starts. A quote follows from that written scope, so the document is where a CISO or head of IT should look first when comparing proposals.

A useful scope names the decisions that drive effort. It should state which PRTG devices and sensor types are in scope, whether the Checkmk Community edition or a commercial edition will run the sites, and who owns the Checkmk sites, the agent rollout and the service discovery rules. It should also list the thresholds and notification rules to be recreated and the parallel-run period in which Checkmk and PRTG alert on the same hosts. Ask the provider to show which items are one-time work, such as the bulk host creation and rule rebuild, and which recur, such as patching the Linux hosts that run Checkmk, backups of the sites and upgrades to later Checkmk releases.

Ongoing support is handled separately. DeployOpen offers retainers for continued support, upgrades and continuous testing, which suits teams that will run Checkmk without an in-house specialist after handover. Compliance preparation, where the monitoring evidence supports an assessment, is scoped the same way: DeployOpen prepares systems, controls and evidence, while independent auditors and certification bodies issue any audit reports. Before signing, confirm the scope, deliverables and timelines in writing, and ask for the quote to be tied to that document.

Migrate from PRTG to Checkmk