Can you export data from SolarWinds Network Performance Monitor before the contract ends?
Yes, for most of your monitoring configuration. A network team facing a renewal, a price change or an exit decision can pull nodes, interfaces, custom properties and alert definitions out of Orion using the Apache-2.0 Orion SDK, SWQL Studio and the PowerShell module. Historical performance data and the Orion configuration itself need a separate plan, because they are stored and exported differently and are not covered by a simple inventory pull. Treat this as a two-track project: an inventory export you can run now, and a retention plan for history that you decide on before the contract date.
This page walks through the inventory track first. It covers how SWQL queries return node and interface records, how custom properties are read alongside them, and how alert definitions are captured so their thresholds and scope can be rebuilt elsewhere. It then turns to historical data, where the practical question is which time ranges, which counters and which report formats your auditors or capacity planners actually need, and whether that history can be kept as flat exports rather than as a running database. The final sections cover the decisions a team should make before exporting, such as freezing change control on the source server and choosing where the export files are stored.
Exact entity names, field names and SDK or PowerShell module versions change between Orion releases, so every query and command in this process must be checked against the SolarWinds documentation for the version you have installed. Confirm the schema on a non-production copy of your Orion database before relying on any export, and record the version you exported from, because that record is what your migration team and any later audit will need.
Which SolarWinds NPM data you can export, and in which format
This table maps each NPM data type to the export method that reaches it (Orion SDK, SWQL Studio or the PowerShell module), the output format it produces, and the limits to confirm before you rely on it. Read each row as a checklist item for your inventory, and treat the limits column as the questions to put to SolarWinds documentation and to a test export in your own environment.
| Data type | Export method | Output format | Limits to confirm |
|---|---|---|---|
| Nodes and node properties | SWQL Studio query or Orion SDK call against the node entities | Tabular query results, exportable to CSV or handled as structured objects in a script | Paging behavior on large node counts, and which node fields are returned by default versus only when selected |
| Interfaces and interface properties | SWQL query joining node and interface entities, run through SWQL Studio or the Orion SDK | Row-based results, one row per interface, suitable for CSV or JSON conversion | Whether interface status and bandwidth fields need separate queries, and how polling-dependent fields are represented |
| Custom properties | SWQL query on custom property tables, or Orion SDK custom property calls | Key and value pairs attached to each node or interface, typically flattened into columns | Data types of each custom property, and how multi-value or empty fields are written out |
| Alert definitions and triggers | SWQL query on alert configuration entities, or Orion SDK read of alert objects | Structured alert records including names, conditions and enabled state, exported as text or JSON | Whether trigger expressions and action links are included, and how notification recipients are referenced |
| Pollers and polling settings | Orion SDK or SWQL query on polling configuration; PowerShell module for scripted reads | Per-object polling intervals and poller assignments in tabular or script output | Which polling options are global versus per object, and whether poller engine settings are exposed through the API |
| Maps and groups | SWQL query on group membership; map layouts usually need a separate check in the web console | Group membership lists are tabular; map layout files are often not returned by the SDK | Confirm in the vendor documentation whether map geometry and background images can be exported at all |
| Credentials handling | Confirm with the SDK and PowerShell documentation before scripting any credential read | Credential records are referenced by name or ID in most query results | Whether passwords or SNMP community strings are returned in clear text, and whether they must be re-entered at the target |
Orion SDK, SWQL Studio or PowerShell: which export path fits which data
The Orion SDK is the most flexible path. It is Apache-2.0 licensed, so your team can read its source and keep scripts under version control without a separate license decision. Developers use it to write scripts that query nodes, interfaces, custom properties and alert definitions, then transform the results into the shape a target system expects. Output is usually a CSV or JSON file written by the script, which is easy to diff between runs and to load into an import tool.
- Typical use: a repeatable extraction of the full inventory, including custom properties that a spreadsheet export would miss.
- Skill level: comfortable with a general-purpose scripting language, HTTP-based APIs and error handling for paged results.
- Output: write each run to a dated folder with a manifest of record counts so a second run can be compared with the first.
- Production risk: large or unfiltered queries add load to the Orion database during business hours. Use a read-only account, page results and schedule runs in a quiet window.
- Credentials: keep the service account and any secrets in a vault or environment variable, never in the script file.
Before the first full run, confirm with your SolarWinds documentation which SDK version matches your Orion release. Check that record counts from the script match what the web console shows for a sample of nodes.
SWQL Studio is the interactive query tool for the SolarWinds Query Language. It suits discovery work: confirming which entities exist, which fields hold custom properties and how nodes relate to interfaces and alerts. Analysts and network engineers who already write SQL can usually build a working inventory query within a short session. The results grid can be exported directly, which makes it a good way to produce a first inventory file for review.
- Typical use: building and checking the inventory query before anyone writes a script, and sampling data for the import mapping.
- Skill level: familiarity with SQL-style SELECT statements and joins. No programming is required.
- Output: export the grid to CSV for review, and save the query text in a repository so the result can be reproduced.
- Production risk: an unbounded SELECT across a large table can slow the database. Add row limits while exploring and avoid joins across high-volume history tables.
- Write access: use an account that can only read. Confirm with your Orion administrator that the account cannot modify monitoring objects.
SWQL Studio is manual, so the output depends on the person running it. Record who ran each query and when, and rerun the saved query before the final migration cutover to confirm nothing has changed.
The PowerShell module suits batch jobs and exports that must run the same way every time, often on a schedule and without an operator present. Administrators who already manage Windows servers can wrap the module's commands in a script, run it from a scheduled task and collect output on a file share. This path fits teams that want exports to match an audit or change process, because the script and its parameters are the record of what was done.
- Typical use: nightly or pre-cutover exports of nodes, interfaces, custom properties and alert definitions, plus a final export just before switchover.
- Skill level: administrator-level PowerShell, scheduled task configuration and basic secrets handling.
- Output: CSV or JSON files named with the run date, stored in a restricted folder with access logged.
- Production risk: a scheduled job that overlaps with a previous run or retries on failure can add load to Orion. Add a lock file, a timeout and a single retry limit.
- Credentials: use a secure credential store tied to the service account. Do not put passwords in the script or in command history.
Run the job from a管理 host that is not the Orion server itself, and confirm the module version and its supported Orion releases in SolarWinds' documentation before you depend on it. Test one full run in a non-production Orion environment if you have one.
What SolarWinds NPM does not export, and how teams work around it
A standard export gives you inventory, not a copy of the product. The cards below cover the items that usually sit outside an export, the risk each one creates during migration, and what to confirm with SolarWinds before you assume a field is absent.
Orion platform configuration and database
The Orion database holds polling settings, credentials references, thresholds and product modules that an SDK or SWQL query does not reproduce as a whole. Treat the database as the system of record for the old platform, not as an export. Back it up and keep it readable for the overlap period. Confirm with SolarWinds which configuration objects are reachable through the Orion SDK and which exist only in the database schema, and ask whether schema-level access is supported for your version.
Stored credentials and secrets
SNMP community strings, SNMPv3 users, WMI and SSH accounts used for polling are stored by the platform and are typically not returned in plain form by an export. Without them, LibreNMS or Zabbix will discover devices but fail to poll them. Plan to re-enter each credential in the new platform's secrets store or macro settings, grouped by role, and rotate them while you do it. Confirm with SolarWinds whether credential values, as opposed to credential names, can be retrieved from your installation.
Dashboard and map layouts
Custom views, network maps, node groupings and dashboard arrangements are presentation objects. Their positions and backgrounds usually do not come out as usable data, so the new platform must be laid out again. Rebuild maps from the exported node and link inventory rather than copying coordinates. Ask SolarWinds which view and map definitions are exposed through the SDK, and whether any can be exported as files, before you plan the manual effort.
Report formatting and scheduled report definitions
Report templates, branding, column choices and schedules are tied to the Orion report engine. Recreating them is usually simpler than converting them, because the output format of the new platform will differ. Keep the existing reports as PDF or CSV archives for audits and monthly comparisons, and record which report each team relied on. Confirm with SolarWinds whether report definitions can be exported as files and whether the output includes the underlying data.
Historical performance samples at full resolution
Raw polling samples are kept for a limited window and are often rolled up into coarser averages as they age. A new platform starts with an empty history, so year-over-year capacity comparisons are lost unless you archive them. Decide which interfaces and metrics matter, export the rolled-up data in CSV, and store it with the timestamps and units intact. Confirm the retention and rollup settings in your own installation, since they vary by configuration.
User accounts and role assignments
Operator accounts, role memberships, account limitations and the links between users and views determine who can see which devices. These do not map one to one onto Zabbix or LibreNMS roles, and a flat copy can grant access that was restricted before. Build the new role model from the access review, then recreate accounts through your identity provider where the platform supports it. Confirm with SolarWinds which account attributes the SDK returns and whether password hashes are exposed (they should not be copied).
How much historical performance data is practical to keep
Keep only a defined window of historical performance data, not the full raw sample history. Raw performance samples in Orion are large and tied to the Orion database schema, so they rarely move cleanly into a new platform. Most teams instead archive a chosen period of reports and summarized data as read-only evidence, then start fresh time series in Zabbix or LibreNMS on the day of cutover. The window itself should come from your own policy, not from a default in this guide.
Set the retention window with the compliance owner and the capacity owner together. Compliance should state which reports, audit trails and availability records must be retrievable, and for how long, based on the obligations that apply to your organization. The capacity owner should confirm how much storage the archive will take and where it sits. Before fixing the window, confirm with SolarWinds which export options your Orion version supports for performance history, since the documented query paths differ in what they return. Record the decision in the migration plan so auditors can trace it.
Export the chosen window through the documented query paths you confirmed, typically SWQL queries or the Orion SDK, and write the results to files that carry their own checksums and a record of the query, the date range and the Orion version used. Store the archive on storage with access controls and a retention label. Treat it as read-only evidence: nobody should edit it, and it should not feed live dashboards or alerts in the new platform. If someone needs historical numbers for a new analysis, they should reference the archive as a source and state the export date, because the archive reflects what Orion held at that moment.
Export sequence from SolarWinds NPM with verification at each step
This sequence captures a point-in-time copy of your Orion inventory, configuration and chosen historical reports, with a check at each stage so the export can be trusted as the source of truth for the migration.
Inventory the Orion instance and version
The network engineer lead records the Orion Platform version, the NPM module versions, the database server and the list of polling engines and additional pollers in a short inventory document. Confirm the version and module list against the Orion web console's About page and the installed components, not memory. The step is done when the inventory is signed by the person who will own the migration and stored with the export package.
Freeze configuration changes
The Orion administrator announces a change freeze for nodes, interfaces, custom properties, alerts and polling settings, and confirms that no discovery jobs are scheduled to run during the export. Record the freeze start time and the names of the people who agreed to it. Verify the freeze by checking the Orion audit or change log for entries after the start time; any entry found means the export must be repeated after the freeze is re-established.
Export nodes and interfaces with SWQL and the SDK
Run SWQL queries in SWQL Studio against the Orion database to pull node and interface records, then use the Orion SDK (Apache-2.0) with PowerShell to write the same results to CSV or JSON. Save the query text alongside each output file. Verify by comparing the node count and interface count in the files with the totals shown in the Orion web console, and by hand-checking a sample of ten nodes, including one with an unusual IP address, against the node details page.
Export custom properties and alert definitions
Export custom property names, types and assigned values for each entity, plus alert definitions with their trigger conditions, reset conditions, severities, time-of-day schedules and notification actions. Store the output as separate files. Verify by counting custom property definitions and alert definitions against the Orion Settings pages, then open a sample alert in the console and confirm each condition and action appears in the exported record.
Export polling and group structure
Export the polling method and interval for each node and interface, the container or group membership, and any dynamic group definitions. Dynamic groups must be exported as query text, not as a static member list, so their logic can be reviewed. Verify by comparing the group count and a sample of group memberships with the Orion Group Management view, and confirm that the polling interval recorded for a sample of interfaces matches the value shown in their settings.
Archive the chosen historical reports
Select the historical reports the business needs to keep, such as availability, interface utilization or capacity reports for named periods, and export each as PDF or CSV from Orion. Store the report parameters with each file so the same period can be reproduced later. Verify by opening each archived report and checking that the date range and entity filter match the parameters recorded. Confirm with the business owners which raw performance data will not be migrated, since keeping raw samples is a separate decision and depends on storage and retention needs in your environment.
Record counts and checksums for each file
Generate a SHA-256 checksum for every exported file and record, in a manifest, the row or record count, the source query or report name, the export time and the Orion version. Verify the manifest by recomputing checksums on a second machine and confirming that every count matches the number recorded in the step where the file was created. Any mismatch means the file is re-exported before the package is accepted.
Run a second export to confirm repeatability
Repeat the node, interface, property, alert and group exports under the same freeze, using the saved query text and scripts without manual edits. Compare the new files with the first set using checksums or a line-by-line diff. Differences in timestamps or export metadata are expected; differences in records are not, and must be investigated before the export is signed off. The step closes when both sets match on content and counts.
What to plan before the SolarWinds NPM renewal or termination
Exporting Orion data is only one part of leaving. The contract dates, licensed modules, export rights and the overlap period decide how much time you have and what you can keep. Work through these items with your procurement or legal team before the export starts.
Confirm notice and renewal dates
Find the notice period, auto-renewal clause and the exact end date of the current term in your SolarWinds agreement or order form. Many teams discover that the notice window closed months before the renewal date they had in mind. Record the deadline in your planning calendar and assign one owner who tracks it. Your procurement or legal team should verify these terms, because the commercial wording is theirs to read.
Map licensed Orion products and modules
List every Orion product and module in use, including NPM, NetPath, PerfStack, and any add-on for IP address management or configuration backup. Compare that list with what the license actually covers, since some features may sit under separate entitlements. The inventory tells you which data sets need an export path and which reports will need a replacement. Ask SolarWinds to confirm the entitlements in writing.
Schedule the export before access ends
Set a target date for the full export that falls comfortably before the date your Orion access stops. Run the nodes, interfaces, custom property and alert definition exports with the Orion SDK and SWQL Studio in one pass, then save the outputs in a versioned location. Plan a second export shortly before cutover to capture changes made during the overlap. Treat the export as a dated deliverable with a named owner.
Budget the parallel run period
Plan for NPM and the replacement platform to collect data side by side until coverage and alerting match. During this period you pay for both systems, staff the operation twice and reconcile discrepancies between them. Decide in advance which alerts, dashboards and device groups must match before NPM is switched off. The length of the overlap depends on your device count and rebuild effort, so size it from your own inventory.
Plan read-only access to archived reports
Auditors, capacity planners and incident reviewers often need historical NPM reports long after cutover. Decide whether you will keep a read-only Orion instance, export reports to PDF or CSV, or store raw exports in an archive. Confirm with SolarWinds whether a read-only or archive option is available under your current terms, and whether it carries a separate cost. Record the retention period your compliance team requires.
Confirm exit support and export rights
Ask SolarWinds in writing what support is available during the exit, including who can help with export questions and how long support continues after notice. Request written confirmation of your export rights and the data retention terms that apply after the contract ends, including how long your data remains in the Orion database. Keep these answers with the contract so that your team does not rely on verbal assurances.
Questions teams ask before exporting SolarWinds NPM data
How long does an NPM data export take?
The time depends on how much inventory there is and how much preparation the export needs, so no fixed duration applies to every environment. The main drivers are the number of nodes, interfaces and custom properties, how complex the SWQL queries are, and how much staging work is needed to shape the output for the target system. A small environment with clean custom properties exports quickly, while one with inconsistent naming or many custom fields needs more validation. Ask any provider for a duration only after they have reviewed your node count, custom property list and target platform in writing.
Can our own team export NPM data without outside help?
Yes, many teams do this in house, and the Orion SDK, SWQL Studio and the PowerShell module are all available to inspect and extract data from your own Orion server. The work is manageable when the inventory is small and the team has time to validate results. Outside help makes the most sense when the team lacks staff with the right skills, when the environment is large or poorly documented, or when a change window is tight. Whichever route you pick, plan for a person who can confirm the exported data matches what engineers see in the console.
What skills does an NPM export need from the team?
The work needs four skill sets: SWQL for querying the Orion database model, PowerShell for scripting extraction and formatting, SQL familiarity for checking results and understanding how data relates across tables, and network knowledge to judge whether the data is correct. Network knowledge matters most at validation, because a query can return a complete list of interfaces that still carries wrong speeds, stale status or misnamed devices. Confirm these skills in your own team before scoping, since the gap determines whether the work stays internal or moves to a partner.
What would an outside consultant deliver, and what must we provide?
A consultant working on a fixed scope should deliver written scope, the export scripts or queries, exported files for nodes, interfaces, custom properties and alert definitions, a validation report comparing exports with the live Orion data, and a list of gaps that need a decision. Your team must supply read access to the Orion server, a named change window, test access to the target platform and a sign-off owner who accepts the export as complete. Without a named sign-off owner, the engagement has no clear end point. Agree these items in writing before work starts.
How is the cost of an export structured?
Export work is usually a one-time cost covering scoping, query and script development, extraction, validation and documentation. A separate, optional cost can cover parallel run support, where both NPM and the new platform run side by side while teams compare results. Costs rise with the number of nodes, the number of custom properties, the number of alert definitions to map and the length of the overlap. DeployOpen does not publish a price list, so ask for a quote that follows from written scope and separates one-time export work from any recurring support.
What happens if the export is incomplete after cutover?
If the export misses data after cutover, the gap usually shows up as a missing device, a missing interface, a lost custom property or an alert that never fired on the new platform. Reduce this risk by keeping NPM available read-only during the overlap, comparing record counts and sample values before cutover, and keeping the raw export files as a reference. Agree in advance who decides whether a gap is fixed by re-export, manual entry or accepted as out of scope. Ask any provider how re-exports and post-cutover fixes are handled in the written scope.
Do we need to keep historical performance data from NPM?
Most teams keep the inventory and alert definitions, and treat historical performance data as a separate decision. Raw polled history is usually large and may not map cleanly into a new platform, so many teams export summary reports or keep NPM read-only for a defined period. Decide which reports auditors, capacity planners or incident reviews need, then confirm with the vendor and your own environment which history can be exported in a usable form. Put that decision in the written scope so the export does not promise more than it can deliver.
How DeployOpen scopes and delivers an NPM data export
DeployOpen treats the export of SolarWinds Network Performance Monitor data as a scoped engagement with written deliverables. We agree what is extracted, in what format, and where it lands inside your own environment before any work starts, so the export can be checked against your inventory.
How we scope
- Confirm which Orion modules, node groups and polling engines are in the export
- List the object types to extract: nodes, interfaces, custom properties and alert definitions
- Agree the output formats, storage location and access controls in a written scope
How we build
- Write SWQL queries and Orion SDK scripts against a copy of your Orion database
- Reconcile exported node and interface counts against the live NPM console
- Map alert definitions to a neutral schema so they can be rebuilt in the target platform
How we hand over
- Deliver the export files with a data dictionary explaining each field and its source
- Document the query and script versions used so the export can be repeated
- Record which historical performance data was kept, summarized or left behind
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first
- Ongoing support, upgrades and re-runs of the export are available as a retainer
- Ask us to confirm any scope change in writing before additional export work begins
