How to export your data from PRTG

How to export data from PRTG before your subscription ends

The PRTG HTTP API exports structured inventory and measurement data, but maps, notification templates, custom sensors and some configuration have to be recreated by hand. That distinction matters when a renewal, a sensor tier change or a move off PRTG is coming, because the monitoring history, device inventory and configuration must leave PRTG intact and usable on the new platform. Many teams discover the gap only after the subscription lapses, when they can still see their data in the web interface but no longer have a reliable record of which devices, sensors and thresholds their alerts depended on. Treat the export as a project with its own date, not a last-minute download.

This page covers what the API returns: device and sensor lists, live data and historic data in XML, JSON or CSV. It then covers the parts that do not come out cleanly, including map layouts, notification templates, custom sensors and settings that sit outside the exported data, and how to inventory them before the export starts. The final section explains how to time the work against your subscription end. Every export is read-only. Requests retrieve data and leave the PRTG installation unchanged, so you can run them while monitoring continues and repeat them as often as needed.

Start with two checks this month. Confirm that an API account with the access you need can log in and read the device and sensor lists, then export one device with its history to see how much data each file holds. Ask your PRTG administrator or partner to confirm which history retention your installation keeps and whether any sensors fall outside what the API returns. Then set the export date against your subscription end, leaving time to rebuild alerts and run both systems side by side. Keep the PRTG licence active until the new alerts have matched the old ones through a full cycle of normal operations, because a lapse can stop the monitoring you are trying to copy.

Export data from PRTG: which objects the API returns, in which formats and with what limits

This table maps each PRTG data type to its export method, format and the limits you must confirm before scripting. Endpoint names, parameters and row limits vary by PRTG version, so treat every row marked to verify as an open item until you test it on your own server. The main takeaway is that live and historic values need separate, time-bound queries, while maps, notification templates and custom sensors usually have to be rebuilt by hand.

Data type	Export method	Format	Limits to confirm
Device list	HTTP API table query for devices (confirm endpoint name)	XML, JSON or CSV as documented	Confirm filter parameters and any row cap in your version
Sensor list	HTTP API table query for sensors under each device	XML, JSON or CSV as documented	Confirm parent, type and status filters; verify paging behavior
Live values	HTTP API query for current sensor readings	XML, JSON or CSV as documented	Values reflect the call time only; schedule repeat pulls if you need a series
Historic values	HTTP API query for a sensor's recorded data by date range	XML, JSON or CSV as documented	Verify date format, averaging interval and maximum records per call
Object settings	HTTP API property query per object ID	XML or JSON as documented	Verify which settings are returned and whether credentials are masked
Maps and dashboards	Not returned as configuration by the API; use screenshots or the web interface	Image or PDF from the interface	Rebuild layouts by hand in the target tool; confirm export options
Notification templates and custom sensors	Not returned as reusable configuration by the API	Not applicable	Document each one manually and recreate it in the target platform

How to call the PRTG HTTP API for a bulk export

Start with an export script that authenticates to the PRTG core server, requests objects by ID or by object type, and writes each response to a file without flattening it. Use a dedicated account and an authentication method that your PRTG version supports, since the options differ between releases and between hosted and on-premises installations. Ask your PRTG administrator which options are enabled on the core server before you write any code. Object lists come from the table endpoints, where a content parameter names the object type, such as devices or sensors, and an ID filter narrows the request to one object's children. Save each raw response exactly as returned, with a filename that records the object type, the ID and the date, so the structure stays intact for later re-import.

The format decision matters more than most teams expect. XML and JSON keep nested relationships and most field values, such as parent device, tags and sensor settings, which a re-import tool needs. CSV is flat and helps with spreadsheets and reviews, but it drops hierarchy and often depends on columns chosen in advance, so treat it as a companion copy that supports review. For historic data, pull in time windows instead of one large request. For example (illustrative), split the range into one-month windows, compare the record count of each file against a rerun, and log any window that fails so it can be retried alone. Confirm the largest response size and any request limits for your version before you pick the window length, because one failed oversized request can waste an entire run.

Give the export account read-only rights. The script only needs to read objects and history, so an account with read access to the relevant objects and no permission to change settings, pause sensors or delete anything limits the damage if the credentials leak from a script, a CI job or a shared workstation. Create the account before the export starts, record which objects it can see, and compare object counts from the API with the web interface for a sample of groups. Keep the credentials in a secrets manager and out of the script. Finally, confirm the authentication options, rate limits and response size limits for your PRTG version with your administrator or the PRTG documentation before the first run, and schedule the full export to finish well before the subscription end date.

What does not export through the API and how to rebuild it

The PRTG HTTP API returns devices, sensors and monitoring data, but much of the configuration around them lives in the PRTG interface and must be captured another way. The cards below cover the items teams most often recreate by hand, with a practical workaround for each. Confirm the exact export scope of your PRTG version with Paessler before the subscription window closes.

Map and dashboard layouts

Maps and dashboards arrange sensors and groups visually, and their positions, backgrounds and linked widgets are presentation settings rather than monitoring data. Treat them as a design asset to recreate, not a file to import. Before the export, capture each map with a full-resolution screenshot and note which sensors or groups each element points to. In the target platform, rebuild these as Zabbix dashboards or Checkmk views, and check that every element you recreated still points to a live host or service.

Notification templates and triggers

Notification rules tie sensor states to recipients, schedules and messages, and the exported sensor data does not carry the full logic that sends an alert. Export the list of notification objects and the sensor-to-notification assignments that the API returns, then record the message text, escalation intent and recipient groups by hand. Use the target platform's action and media type model to rebuild each rule, and test each one with a controlled sensor failure before the old system is switched off.

Custom sensors and scripts

Custom sensors run scripts or queries that exist on the PRTG probe host, so the script logic, its parameters and any stored credentials stay outside the data export. Copy each script from the probe into version control, note its runtime dependencies and the arguments each sensor passes, and record which credentials it used without copying the secret values. In the target platform, decide whether each check becomes a native template item, a user parameter on an agent, or a Checkmk local check, and confirm each one returns the same value before retiring it.

User accounts and access rights

Users, groups and permission inheritance define who can see and change monitoring objects, and they are managed in PRTG rather than as plain monitoring records. Export the user list you can access, then map each PRTG group to a role or user group in the target tool and document the access level for each. Passwords and multi-factor settings should be reissued or reset in the new system, not transferred, and access reviews should confirm that no former staff keep rights.

Schedules, reports and maintenance windows

Scheduled reports, recurring maintenance windows and business-hour definitions run inside PRTG and are not returned as data an importer can read. List every report that leaves the system, its recipients and its frequency, and list every maintenance window that suppresses alerts. Rebuild each one as a scheduled report or downtime rule in the target platform, and check the time zone and calendar settings against the originals, since a shifted window can either hide real outages or flood on-call staff.

The export sequence from inventory to verified archive

This sequence turns a live PRTG installation into a dated, checksummed archive of configuration, current values and history that you can verify before the subscription ends. Each step names what it produces and how you confirm it is complete.

Freeze and document the current configuration
Before any export, the monitoring owner records the PRTG version, the probe and group layout, the list of devices, sensors, maps, schedules and notification triggers, and the people who receive alerts. Take a dated screenshot or PDF of each map and a copy of each notification template, since these are the items the API will not return in a reusable form. The output is a configuration inventory signed off by the team. It is done when every probe, group and map on the PRTG server appears in the document with an owner.
Create a read-only API account
Create a dedicated PRTG user with read-only rights on the object tree you need to export, and generate its API access for scripted calls rather than reusing an administrator login. Confirm the account's access in the PRTG interface and note which groups it can see. The output is a named service account and a record of its permissions. It is done when a test call for the device list succeeds and a write attempt through the same account is refused.
Export the device and sensor lists first
Call the PRTG HTTP API to retrieve the device and sensor lists in a structured format such as XML, JSON or CSV, then save each response as its own file with the request URL and time recorded. These lists define the scope for every later step, so they come first. The output is a device list and a sensor list with IDs, names, parent groups, types and tags. It is done when the sensor count in the export matches the count shown in the PRTG interface for the same object tree.
Export live values
Use the API to pull current readings for each sensor, again saving raw responses with timestamps. Live values give you a snapshot of what the monitored estate looked like at the moment of export and help you check that sensor states, thresholds and units carried over correctly. The output is a dated live-values file per export run. It is done when a sample of sensors, chosen across device types, shows the same status and last value in the interface and in the file.
Export historic data in time windows
Request historic data sensor by sensor or group by group, splitting the date range into fixed windows so that a failed request can be repeated without redoing the whole history. Record the window boundaries, the sensor ID and the response size for each call. The output is a set of historic files, one per sensor and window, with a manifest that lists them. It is done when every sensor in the sensor list has a file for every window, and any gaps are logged with the reason.
Store raw files with checksums
Keep the raw responses exactly as the API returned them, in a write-once or versioned location with access restricted to the monitoring and compliance owners. Generate a checksum for every file and store the checksum list separately from the data. Store the matching PRTG version and export script version beside the archive. The output is an archive folder with an index file of names, sizes, timestamps and SHA-256 checksums. It is done when a second person can recompute the checksums and get identical values.
Run the verification checks
Apply the checks in the verification section to the archive: compare object counts against the interface, confirm checksums, sample historic values against the graphs and confirm that the manifest covers every window. Record the result of each check, the person who ran it and any exceptions with a decision. The output is a signed verification log. It is done when every check has a pass result or an approved exception.
Repeat the export before the final cutoff
Run the same sequence again close to the end of the subscription, because sensors and history collected after the first export would otherwise be missing. Compare the second export with the first to find new devices, changed sensors and additional history, and keep both archives. Confirm with your vendor and contract owner the exact date when access ends and the last day the subscription remains active. The output is a final archive and a delta report against the first run. It is done when the delta report is reviewed and the final checksums are recorded in the migration log.

How to verify that the PRTG export is complete

Completeness is proven by comparison, not by trust in the export script. Before you decontaminate or decommission anything in PRTG, compare object counts per type between the PRTG interface and the exported files: groups, devices, sensors and, where you exported them, notifications and maps. Record each count from the PRTG web interface on the day of export, then count the rows or records in the XML, JSON or CSV output. Any gap is a failed export until you can explain it, such as a sensor paused or deleted between the two counts. Repeat the count on the same day for every export run, not only the first.

Counts alone can hide swapped or orphaned records, so also check that sensor IDs, parent device links and sensor types match between source and export. Pick a sample of devices and confirm that each sensor appears under the correct parent and carries the same sensor type it had in PRTG. Keep the raw files exactly as the API returned them. Store a checksum for each file and do not edit, reformat or re-save them during analysis; work on copies. Sample historic values at several time points against the source, including early, middle and recent periods, because a truncated history often looks correct at the first timestamp. Confirm which fields your target platform needs before deciding what counts as a pass, since a field the target requires but the export omits is a failure even when counts match.

Treat the export log as evidence in its own right. It should record the date and time, the PRTG server and version, the account used, the API calls made, the output formats, the file checksums and any errors or retries. Ask your compliance or retention owner to review the verification results and sign off the archive before the PRTG subscription ends, because sign-off tells you who accepted the data and when. Ask them which retention period and evidence standard apply to the monitoring history, since that answer decides how long the raw files and logs must be kept. Keep the signed record with the archive, not in a team folder.

What to plan before the PRTG subscription renewal or termination

Most of the export work is decided well before the subscription ends. The cards below cover the contract questions, the test runs, the retention and format choices, the cut-off for the final export and the read-only period that follow from them.

Confirm contract end and notice terms

Find the exact end date of your PRTG subscription, the notice period for renewal or cancellation, and whether your reseller or Paessler holds the agreement. Note the sensor count and any auto-renewal clause. These dates set the deadline for every other step, so the export timeline should be built backward from them. Ask Paessler or your reseller to confirm the current terms in writing, because licensing and renewal conditions can change.

Run a full test export early

Run the export script against the full device and sensor tree well before the deadline, not only a sample. Expect failures on sensors with unusual names, special characters, paused objects or large history requests, and fix them while PRTG is still fully licensed. A test run also shows how long a complete export takes in your environment, which tells you how much buffer to leave.

Decide retention period and format

Decide how much historic data the new platform needs, and in which format it will be kept. The PRTG HTTP API returns historic data as XML, JSON or CSV, so choose the format that your import tooling and auditors can read. Record the decision in writing, since it determines the export volume, the storage you need and what you can later prove about past performance.

Schedule the final export

Set the cut-off for the final export after the last data point the team needs, such as the end of a quarter or a reporting period, and leave time to verify it. Export again after the cut-off if the business still needs recent data. Confirm with the owners of capacity planning and incident reviews which dates they rely on before fixing the cut-off.

Keep PRTG available read-only

Plan to keep the existing PRTG installation running after the subscription ends, so the team can compare old and new alerts and look up history during a parallel run. Confirm with Paessler what a lapsed subscription allows, such as continued access, reduced sensors or a change to the monitoring mode, because this decides whether the read-only period is possible. Keep the server, its database and access accounts under your normal controls.

Request data handling terms in writing

Ask Paessler or your reseller in writing what happens to your monitoring data, configuration and any hosted instance when the agreement ends. Cover deletion timing, whether data can be retained by the vendor, how a hosted instance is decommissioned, and whether you can request confirmation of deletion. Do not assume these terms. Ask for the current policy and keep the written answer with your exit records.

Questions teams ask before exporting data from PRTG

Can our own team run the PRTG export without outside help?

Yes, many teams can, provided someone has the skills to work with the PRTG HTTP API. The API returns device and sensor lists, live data and historic data in XML, JSON or CSV, so the export is scripted work: authenticate, loop over the device and sensor objects, request the time ranges you need and write the output to files you can check. The engineer should be comfortable parsing those formats and should know enough about the target tool to map what is exported. The export also returns values, not the logic behind them, so someone who understands what each sensor measures must review the results. Outside help becomes more useful when the estate is large, sensors are heavily customized or the team has no time to script and test.

How much effort do the export and rebuild take?

The effort is driven by what you have in PRTG, not by a fixed rule. The main drivers are the number of sensors, how far back history must go, the number of maps, the number of notification templates and the number of custom sensors. The API covers device and sensor lists and data, but maps, notification templates and custom sensors must be rebuilt by hand in the target tool. Before you ask for a quote, count each of these categories and note which sensor types are in use, because some types map cleanly to standard templates and others need design work. A written, fixed scope lets you compare proposals on the same inventory.

How long does a PRTG export and rebuild take?

No single duration applies to every estate, so treat any figure you hear with caution and build your own schedule from your inventory. The length depends on the size of the estate, the history window you choose, how much of the rebuild is manual, how quickly the target platform is ready and how long the test window and sign-off take. Work backwards from your subscription end date and allow time for a parallel run before cutover. For the target, choose a stable release line: Zabbix standard releases are supported for 12 months, while LTS releases are supported for 5 years, which may suit a longer rebuild. Check the current life cycle details with the vendor before you commit to a version.

What access and inputs must our team provide for the export?

The export needs a small set of inputs that should be agreed before work starts:

API access to the PRTG server, using an account with read-only rights so the export cannot change monitoring configuration. Confirm the authentication options for your PRTG version in its documentation.
A network path from the machine running the export to the PRTG server.
A test window agreed with the monitoring and operations teams, so exports do not affect live polling or alerting.
A named owner who signs off the device inventory, the sensor mapping and the alert parity checks.
Contacts for the people who own maps and notification rules, since they know which items matter in practice.

Can historic PRTG data be imported into Zabbix or Checkmk?

Do not assume that old PRTG values will load into the target tool as history. In most projects the historic data is exported and archived in XML, JSON or CSV, so it stays available for reporting, audits or troubleshooting. Some teams import a limited period into the target or a separate analytics store, but that depends on the target's import methods and its data model. Confirm the import path in the target's documentation and test it on a sample before you plan around it. Many teams also keep PRTG readable until the archive is verified, so they can compare old and new values during the transition.

How do we time the export against the PRTG subscription end?

Start the inventory and test exports well before the subscription end date, because the rebuild usually takes longer than the export itself. Run PRTG and the target in parallel until alerts from the new system match the old ones, then take the final historic export after the last validated configuration change but before access ends. Ask the vendor in writing what access remains after the subscription ends and whether historic data stays readable. Store the exports with checksums and a record of what was exported and when, so the archive can be verified later.

Which PRTG objects does the API export, and which must we rebuild?

The API covers the core inventory and data: device lists, sensor lists, live values and historic values in XML, JSON or CSV. Maps, notification templates and custom sensors do not come across as ready-to-use objects, so plan to rebuild them by hand in the target tool. Also check schedules, access rights, user accounts and any custom scripts or integrations that depend on PRTG, because their handling depends on your setup. Record each object type in a checklist with its owner and status, and confirm the exact export fields for your PRTG version before writing any script.

When should we bring in outside help for the export?

Consider outside help when the estate is large, when many sensors are custom, when the team lacks time to script and validate the export, or when the cutover carries high operational risk. DeployOpen plans, implements, integrates, documents and supports self-hosted open-source monitoring inside your own infrastructure, and most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. A quote follows from that written scope. For compliance work, DeployOpen can prepare systems, controls and evidence for an assessment, but independent auditors and certification bodies issue any audit report or certification.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source monitoring inside your own infrastructure, so a PRTG data exit is handled as a fixed-scope piece of work with written deliverables. The work covers what to pull from PRTG, where it lands, how it is checked and how the exit is timed against your subscription end.

How we scope

Inventory which PRTG devices, sensors, groups and historic data sets must leave, and which can be retired.
Agree in writing the export formats (XML, JSON or CSV) and the target platform for each data set.
Record the manual rebuild list for maps, notification templates and custom sensors before work starts.

How we build

Script read-only API pulls from the PRTG HTTP API into your own storage, with credentials scoped to export only.
Validate exported device and sensor counts against the PRTG console so gaps are caught early.
Test the same extracts on a non-production copy of the target platform before any production load.

How we hand over

Deliver extraction scripts, a data map and a reconciliation report showing what was exported and what was rebuilt.
Document the manual rebuild items with owners, so maps and notifications are not lost at subscription end.
Walk your operations team through the runbook and keep a dated record of the final export run.

How we support

Fixed-scope engagements close on written acceptance of the deliverables and the reconciliation report.
Ongoing support, upgrades and continuous testing of the target platform are available as a retainer.
Ask any provider, DeployOpen included, to confirm the export window and API access terms against your PRTG licence before work starts.