Export your data from New Relic before the contract ends
If your New Relic renewal or pricing change is forcing a decision, start by knowing what New Relic documents as the export path. The NerdGraph historical data export requires Data Plus and a core or full platform user, and it returns the results of NRQL queries you define, not a full account backup. Plan your exit around that distinction before the contract end date, because anything you do not query is not in the export. Within those limits, the export can return up to 200,000,000 data points per export, compared with the usual 5,000 NRQL result limit, and it has no query timeout. Results arrive as one or more gzip-compressed JSON files of about 100 MB or less, each download link is valid for 6 hours, and the files themselves are valid for a week. The export cannot query live data or the most recent 12 hours, and it does not allow aggregation functions, FACET, TIMESERIES, JOIN or subqueries. Confirm with New Relic whether your account's historical export limit of two concurrent exports is the default for your contract.
Dashboards, alert conditions, workloads, tags and account configuration are not part of this export, so record them separately, for example by exporting dashboard JSON and alert definitions through your own process, and keep a written inventory of every alert condition that depends on a metric you will need to rebuild in Grafana or Prometheus. Ask your New Relic account team to confirm in writing which data types your Data Plus contract covers and whether a custom retention or extended export arrangement is available. Then run one test export for a short, known time window and check the row counts and file structure before you commit the full migration timeline.
Which New Relic data you can export and in what form
This table maps the kinds of New Relic data you might want to keep to what the NerdGraph historical data export can return. Read it as a filter: the export only covers NRQL query results within its limits, so anything outside those results needs a different capture path. The main takeaway is that the export gives you data points, not a full copy of account configuration.
| Data or need | Can the historical export return it? | Limits to plan around | What to do for the rest |
|---|---|---|---|
| Event data queried with NRQL (for example, transactions or custom events) | Yes, as query results in JSON | Requires Data Plus and a core or full platform user; NRQL must avoid aggregation functions, FACET, TIMESERIES, JOIN and subqueries | Rewrite queries as raw row-level selects, and keep the exact NRQL in your export log |
| Metrics or aggregated views that depend on FACET or TIMESERIES | No, those NRQL features are not allowed | Aggregated series must be recalculated from raw rows, which increases file count and processing | Export raw events and rebuild aggregations in your own backend, such as Prometheus or ClickHouse |
| Data from the last 12 hours or live data | No | The export cannot query live data or the preceding 12 hours | Keep the live pipeline running until cutover, then export the older window |
| Large historical result sets | Yes, in multiple files | Up to 200,000,000 data points per export and no query timeout; files are gzip-compressed JSON of about 100 MB or less | Plan for several files per export and confirm total row counts against your retention needs |
| Export job concurrency | Limited | No more than two concurrent historical data exports per account by default | Schedule exports in sequence and ask New Relic whether your account default can change |
| Dashboards, alert conditions, account settings and users | No, the export returns data points, not configuration | Configuration must be rebuilt by hand in the target tool | Document dashboards and alert policies separately before cutover |
| Download files | Available for a limited window | Result files are valid for a week, and each download link is valid for 6 hours | Download and store results in your own object storage promptly after each export completes |
What the historical export cannot return and how to work around it
The historical export trades query flexibility for volume, so several NRQL features and time windows are unavailable to it. Each limit below changes what you can move out of New Relic, and each has a workaround that depends on what you need to keep. Check these limits against your queries before you plan the export window.
The 12-hour cutoff
The export cannot query live data or the preceding 12 hours, so the newest telemetry never appears in an export run. Schedule your final export to end at least 12 hours before the cutoff you need, and treat that gap as a window to cover with a live pipeline. Start an OpenTelemetry pipeline that sends the same telemetry to your target backend now, so the gap is filled from the day you begin. Confirm the cutoff against the current NerdGraph documentation before you set a schedule.
No aggregation functions in exports
Aggregation functions are not allowed, so the export returns raw event rows rather than summarized series. Keep the raw event shape, including attribute names and timestamps, so you can rebuild averages, percentiles and counts in the target tool. This means larger files and more post-processing, but it avoids losing detail you cannot recover later. Plan storage for raw rows and check whether your target system can reproduce each aggregation you rely on.
No FACET, TIMESERIES or JOIN
FACET, TIMESERIES, JOIN and subqueries are unavailable, so grouping by attribute, time bucketing and combining event types must happen after export. Inventory the dashboards and alert queries that use these clauses, because each one needs a replacement query in the target tool. Group and bucket in PromQL, LogQL or your SQL engine, and join on a shared key such as a trace or service identifier. Test a sample export against each replacement before cutover.
Dashboards, alerts and user settings
Dashboards, alert policies, notification channels and user settings are outside the historical data export, so none of them move with the data. Export a JSON or NRQL inventory of each dashboard and alert condition by hand, then rebuild them in Grafana or your chosen tool. Record thresholds, evaluation windows, notification targets and owners so the rebuilt alerts behave the same way. Assign a named owner to each rebuilt alert before you retire the New Relic version.
Keep a parallel OpenTelemetry pipeline
Because the export is historical, it cannot supply continuous data after the cutoff. Instrument applications with OpenTelemetry and send the same OTLP telemetry to New Relic and your self-hosted backend in parallel. New Relic documents native OTLP ingest, which makes this practical during the transition. Compare the two streams for a defined period before you stop sending to New Relic, and confirm that attribute names match what your queries expect.
Run a complete export in a fixed sequence with verification
This sequence turns an open-ended export into a set of bounded, downloaded and checked files, so that nothing is deleted until every query has been reconciled with the data you stored.
Confirm Data Plus and user type
Before any query is written, the account owner confirms with New Relic that the account has Data Plus and that the person running the export holds a core or full platform user type. The historical data export requires both, so a missing entitlement stops the work here rather than halfway through a batch. Record the account ID, the named operator and the confirmation in the project log. The step is done when a test export request is accepted for the account.
Inventory queries and time windows
Build a register listing every NRQL query the export must cover, grouped by event type, with the time window each one needs and the business owner who asked for it. Check each query against the historical export restrictions: it cannot read live data or the preceding 12 hours, and it cannot use aggregation functions, FACET, TIMESERIES, JOIN or subqueries. Queries that depend on those features need to be rewritten as raw event selections before export. The register is complete when every query has a reviewed window and a status of ready or rewrite.
Split windows to fit the limits
Divide each query's time window into slices small enough to stay under the 200,000,000 data point ceiling per export and to produce files near the roughly 100 MB gzip-compressed limit. Choose slice size by testing a small window first and measuring how many rows and files it returns, then scale the slices for the full range. Name every slice with its query, event type and start and end timestamps so it can be traced later. The output is a slice manifest where each row maps to exactly one export request.
Queue exports within the concurrency default
Submit the slices through NerdGraph in a queue that never runs more than two historical exports at once, which is the default per-account limit. The operator tracks each request ID and its status in the manifest, and records any request that fails or is rejected so it can be resubmitted without duplication. Ask New Relic to confirm the current limit for the account if the default has been changed. The step is complete when every slice has a request ID and a final status.
Download files within the link validity
Retrieve each completed export as its gzip-compressed JSON files as soon as it is ready, because each download link is valid for 6 hours. A script or the operator downloads every file part, stores it on the organization's own storage with its slice name, and records the file size and a checksum at the moment of download. Any link that expires is regenerated by re-requesting that slice, not by guessing URLs. The step is done when every expected file part for every slice is stored and logged.
Copy files to durable storage before the one-week limit
New Relic keeps the result files for a week, so the team moves every verified download into its own retained storage well before that deadline. The copy should keep the manifest, file names, checksums and the original request IDs together, with access limited to the named owners and the security team. Confirm the storage location, encryption and backup policy with your own data governance rules, since those are not defined by New Relic. The step is complete when a second copy of every file exists and its checksum matches the logged value.
Verify row counts and checksums
For each slice, the team decompresses the stored files, counts the JSON records and compares the total with the row count for the same NRQL window reproduced in a separate, supported query, where the time range allows. Checksums of the stored files are compared with the values recorded at download, and any gap, duplicate or mismatch opens a ticket against that slice. The output is a signed reconciliation sheet that lists each query, its window, its counts and its checksum result. Where live queries cannot cover the window, the discrepancy is documented rather than assumed away.
Delete source data only after sign-off
Source data stays in place until the reconciliation sheet has been reviewed and approved by the data owner, the operator and whoever holds compliance responsibility. Only then is any local copy or downstream staging table removed, and the deletion is recorded in the project log with the date and approver. Retain the manifest and reconciliation sheet for as long as your retention policy requires, since they are the evidence that the export is complete. The step is done when the sign-off is filed and the deletion record exists.
How the export runs step by step in NerdGraph
The export starts as a NerdGraph request, so the first decision is the query and time window, not the script. The account needs Data Plus and a core or full platform user. Plan the window to end at least 12 hours before the request, because the export cannot read live data or the preceding 12 hours. Also note that the export does not allow aggregation functions, FACET, TIMESERIES, JOIN or subqueries, so any aggregation must happen in your target store. Each account allows two concurrent exports by default, so queue jobs rather than firing them in parallel. Confirm the current mutation syntax and field names in New Relic's historical data export documentation before you write code.
After submission, the script polls the export status until it reports completion, then retrieves the results. Expect one or more files, each about 100 MB or less of gzip-compressed JSON, and build the downloader to handle any number of them. Download links expire after 6 hours, so the script should fetch files promptly and request a fresh link if one has lapsed. The result files themselves remain valid for a week, which gives you time to recover from a failed load without rerunning the export. Confirm the exact status values and the link fields in the current documentation, since these names are the most likely to change between releases.
The loader should be planned around retries and row counts. Decompress and parse each file in a streaming fashion so a large file does not need to fit in memory, and map the record fields to your target schema before loading. Make loads idempotent, keyed on account, query and time range, so a re-run does not duplicate rows. Keep each export's time window small enough that its results stay within the 200,000,000 data point limit, and reconcile counts per window against the source before you retire New Relic data. Illustrative example: if a window fails halfway, you re-run only that window instead of the whole history. Choose the target store early, whether object storage, a relational or columnar database, or Loki for logs, because it determines the schema work.
What to plan before the New Relic renewal or termination
Exporting from New Relic is one step in a longer exit, and the export window, file retention and cutover plan all depend on when your contract ends. The cards below cover the decisions to make early, so the historical export, the parallel run and the rebuilt dashboards finish before access to the account is lost.
Set the export window against the contract end
The historical data export cannot query live data or the most recent 12 hours, so the newest data you need will be missing from any export. Work backward from your contract end date and decide which time range must be exported and how far before termination the export must start. Confirm with New Relic how the historical export behaves as your subscription changes, because the account may lose access to the feature before the contract formally ends.
Confirm the Data Plus cost first
The historical data export requires Data Plus and a core or full platform user, so it is a prerequisite you must confirm before planning anything else. Ask New Relic in writing whether Data Plus is included in your current agreement, what it adds to the renewal, and whether it is billed for the export period only. Any of these answers can change the timeline and the budget for the exit.
Plan for one week of file retention
Exported results are valid for about a week, and each download link expires after 6 hours. Build a storage step into the runbook: download each file as soon as it is ready, verify it, and copy it to your own object storage or archive. Assign an owner for each export batch so no file is left in the portal when its window closes.
Dual-ship OTLP during cutover
New Relic, Datadog and Dynatrace all document OTLP ingestion, so instrumentation that already uses OpenTelemetry can send the same telemetry to New Relic and a self-hosted Collector at once. Run both backends in parallel long enough to compare dashboards and alerts before you switch off the New Relic exporter. Check whether each service still uses a New Relic agent, since agents cannot dual-ship in the same way.
Rebuild dashboards and alert conditions
Exported JSON holds data, not NRQL dashboards or alert policies, so every dashboard and condition must be recreated in Grafana or another target. Inventory the dashboards and alert conditions your on-call and business teams use, and mark which ones are critical. Test each rebuilt alert against the same incident history before you retire the New Relic version.
Decide which historical data is worth moving
Historical export is limited to 200,000,000 data points per export and must be split by time range, so moving everything is rarely practical. Choose data by use: compliance evidence, incident post-mortems, capacity baselines and SLO history need different retention. Data you will not query again can stay in an archive with a documented schema, or be dropped after you record the decision.
Questions teams ask before exporting New Relic data
How much does a full New Relic data export cost?
The export itself is billed through your New Relic agreement, and the main cost driver is whether the account has Data Plus, which the historical data export requires along with a core or full platform user. The rest of the cost is labor: scripting the NerdGraph queries, storing and verifying the returned files, and loading them into a destination. Cost rises with the number of data points, the number of NRQL queries that must be split into windows, and the number of exports that must run. Ask New Relic to confirm in writing what Data Plus adds to your current contract, and ask any implementation partner for a fixed-scope quote based on your query inventory.
How long does a New Relic export take to plan and run?
The timeline depends on how much data you need, how many queries you have, and how quickly you can build and check the export scripts. New Relic allows no more than two concurrent historical data exports per account by default, so large backfills are serialized and run for longer. Each export can return up to 200,000,000 data points with no query timeout, which means the limiting factor is usually your own process rather than the platform. Confirm the concurrency limit for your account with New Relic before you plan the schedule, and agree on a timeline in writing if you bring in outside help.
What skills does an in-house New Relic export need?
You need people who can write NRQL within the historical export restrictions, script calls to the NerdGraph API, and handle compressed JSON at volume. The team also needs a storage plan for files that remain valid for a week, with each download link valid for 6 hours, so downloads must be automated or scheduled. A verification plan matters as much as the export: compare row counts and time ranges against New Relic results for a sample window, and record checksums for each file. Someone should own the schema mapping for the destination so the data remains usable after the export.
Can our own engineers run the New Relic export without a partner?
Yes, many teams do the work in house if they have the NRQL, scripting and storage skills described above and time to test before the working window closes. The main risks are missing the restrictions that apply to historical exports, such as no aggregation functions, FACET, TIMESERIES, JOIN or subqueries, and failing to account for the 12-hour cutoff. A partner is useful when the query inventory is large, when audit evidence of the export is required, or when the team cannot spare engineers for the verification work. Whichever route you choose, write down the scope and acceptance checks before work starts.
Why does the 12-hour cutoff matter for an export?
The historical data export cannot query live data or the most recent 12 hours, so the newest telemetry will not appear in the export. Teams that plan a one-time cutover must either keep sending data to New Relic until the export is complete and then run a short gap export, or accept a documented gap. This is a common source of missing data in migration reports, so define the start and end timestamps in your runbook. Confirm the exact behavior of the cutoff with New Relic documentation before you finalize the windows.
What happens to data older than the working window?
Data outside the window that the export can reach is not returned by that export, so older history needs a separate plan. Whatever New Relic retains for your account is governed by your contract and retention settings, so confirm the retention period in writing before you assume any history is available. If you need older data, ask whether it was already exported or stored elsewhere, and decide whether the destination only needs recent data for dashboards and alerts. Keep a record of what was exported and what was not, so auditors and engineers know where the boundary sits.
How long do exported result files stay available?
Exported results arrive as one or more gzip-compressed JSON files of about 100 MB or less, and the files are valid for a week. Each download link is valid for 6 hours, so scripts should fetch and store files within that window rather than relying on links saved for later. Plan storage for the compressed files and the decompressed copies, and keep a checksum for each file so you can prove the copy matches what New Relic returned. Store the files in your own controlled location with access rules that match the sensitivity of the data.
How to verify an export and keep an archive you can use
Verify every export before you rely on it. Run the same query as an NRQL query where the result still works, restricted to a time window that ends before the 12-hour cutoff, and compare the row count and time range against what the export returned. The export cannot query live data or the preceding 12 hours, and it does not allow aggregation functions, FACET, TIMESERIES, JOIN or subqueries, so many of the aggregated checks your team uses will not carry over. Where a direct comparison is impossible, sample a set of records by timestamp and by key attributes, check that fields such as timestamps, durations and identifiers are present and parse correctly, and write down what you could not check. Confirm the exact row limits and file behavior for your account in New Relic's documentation before you plan a large pull, because a single export can return up to 200,000,000 data points across one or more files.
Record the query and the provenance of every file. Store the NerdGraph request, the account ID, the time range, the export date, the number of files and their checksums next to the JSON. The download links expire after 6 hours and the result files are only valid for a week, so the files you keep are the only copy of that output once the window closes. Use a naming scheme that ties each file to its query and time range, and keep a manifest that lists every file in the set so a missing part is obvious. Also state plainly that the export is a data extract. It does not carry dashboards, alert conditions, workloads, tags or the logic behind them, so keep those definitions in version control and do not treat the JSON as a replacement for the New Relic configuration or for the alerting you still depend on.
Choose the archive format for the people who will read it. Gzip-compressed JSON suits engineers who will load it into a script, a notebook or a database, but an auditor or a finance reviewer may need a flat table, a CSV view or a documented schema instead. Decide who must read the archive in five years, what tools they will have, and whether they need to query it or only prove what it contained. Write a short data dictionary that explains each field the export returned and any transformation you applied, and store it beside the files. Confirm with your security and records teams where the archive must live, how long it must be kept and who may access it, since telemetry can contain personal data or sensitive operational detail.
How DeployOpen scopes and delivers a New Relic data exit
DeployOpen plans and delivers the export of New Relic data as a fixed-scope engagement inside your own infrastructure. The work covers which NRQL datasets matter, how exports are run and stored, and how the results are loaded into a self-hosted store you control.
How we scope
- Inventory the NRQL datasets and retention periods your teams actually need to keep, and confirm which of them are covered by the historical data export.
- Confirm the New Relic account has Data Plus and a core or full platform user before any export work is planned.
- Agree in writing how recent data within the 12-hour cutoff will be captured by a separate path, and which query shapes must be rewritten.
How we build
- Script the historical data export through NerdGraph, splitting time windows so each result stays within the 200,000,000 data point limit.
- Store gzipped JSON results in your own object storage and checksum every file so the archive can be verified later.
- Load the archive into a self-hosted store and test sample queries against the original New Relic results before accepting the data.
How we hand over
- Document each export job, its time windows, file naming and the steps to rerun a failed window within the one-week file validity period.
- Deliver a reconciliation report comparing row counts and sample values between the New Relic export and the archived copy.
- Hand over runbooks, access controls and retention settings so your own team can operate the archive after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing of the archive are available as a retainer after handover.
- Confirm with New Relic which export limits, concurrency defaults and file lifetimes apply to your account at the time of work.
- Review the written scope with your security and compliance leads before each new export wave or change to retention.
