How to migrate from New Relic to Grafana and Prometheus with OpenTelemetry
The migration is mainly a matter of re-pointing telemetry that already reaches New Relic at a self-hosted OpenTelemetry Collector, sending metrics to Prometheus and traces to Jaeger, and then rebuilding NRQL dashboards and alert conditions as Grafana dashboards and Prometheus or Grafana alert rules. Teams usually start this work because of a renewal, rising ingest costs under per-GB billing, or a data residency requirement that the current New Relic region does not meet. Platform or SRE teams normally own it, because they already run the clusters, the pipelines and the on-call rotation that depend on these signals. An implementation partner is often brought in for the Collector configuration, hardening and the parallel run, but the internal team still needs to own the alert logic. The instrumentation side is the lower-risk part. New Relic documents native OTLP ingest, so applications that already send OTLP can often be pointed at a Collector with a changed endpoint and a second exporter, which lets you run both backends side by side before cutover. Applications still using New Relic's own agents need code or agent changes first, and that effort is usually larger. Ask engineering to inventory each service by agent type, language and telemetry signal before estimating anything. The higher risk sits in the rebuild: NRQL queries, alert thresholds and notification policies have no automated converter, so each one must be recreated and checked against live data. Plan a parallel run long enough to cover your normal business cycles, and confirm with the Collector and Prometheus documentation which metric names, labels and histogram shapes change when telemetry arrives through OTLP. Prometheus stores data on a single node by default, with 15-day retention unless you change it, so decide early whether you need long-term storage and a clustered setup, and confirm that choice against your retention obligations. Grafana needs MySQL or PostgreSQL for production and high availability, so a database backup plan belongs in the scope from day one. Set a cutover checklist that covers alert routing, on-call acknowledgement, dashboard sign-off by each service owner and a documented rollback path to New Relic until the parallel run has passed.
Which New Relic capabilities map cleanly to Grafana and Prometheus
This table maps each New Relic capability a migrating team relies on to its self-hosted OpenTelemetry, Prometheus, Jaeger, Grafana or Alertmanager equivalent. Read the status column as clean for a direct substitute, needs rework where the logic must be rebuilt, and gap where no equivalent exists. Confirm APM depth and NRQL-specific features against your own usage before committing.
| Capability | New Relic side | Self-hosted equivalent | Status |
|---|---|---|---|
| OTLP ingest | Native OTLP endpoint on ports 443, 4317 and 4318 | OpenTelemetry Collector receivers and exporters, dual-export during cutover | Clean |
| Metrics storage and query | NRQL over New Relic metrics | Prometheus scraping or OTLP receiver, queried with PromQL | Needs rework |
| Distributed traces | Trace explorer built on New Relic APM | Jaeger v2 on OpenTelemetry Collector components, with Grafana trace views | Needs rework |
| Dashboards | New Relic dashboards written in NRQL | Grafana dashboards written in PromQL or the query language of each data source | Needs rework |
| Alert conditions and notifications | New Relic alert conditions and policies | Prometheus alerting rules, Alertmanager routing and Grafana alerting | Needs rework |
| User access and SSO | Billable user types with role-based access | Grafana roles, with SAML and SCIM only in Grafana Enterprise | Needs rework |
| Retention | Retention set by New Relic account settings | Prometheus local retention of 15 days by default, longer history needs remote storage such as Grafana Mimir | Needs rework |
| APM depth and NRQL-only features | Language agents, service maps and NRQL functions | Depends on OpenTelemetry instrumentation coverage and your custom queries | Gap |
What data and configuration you can move, and what you must rebuild
Instrumentation is the part of a New Relic exit that transfers most cleanly, because OpenTelemetry sends the same telemetry to any compliant backend. Dashboards, alert conditions, notification routing and historical data do not carry over automatically, so each needs a named owner and a decision before cutover.
Instrumentation and OTLP exporters
Applications already sending OpenTelemetry data to New Relic can usually be pointed at a self-hosted OpenTelemetry Collector by changing the exporter endpoint and credentials. Applications still using New Relic's proprietary agents need to be re-instrumented with OpenTelemetry SDKs, which is a separate piece of work. Check which services use the OTLP path and which use vendor agents, and confirm each language's SDK maturity before you commit.
NRQL dashboards and queries
New Relic dashboards are built on NRQL, which does not convert to PromQL or Grafana queries automatically. Each dashboard needs to be rebuilt panel by panel, and metrics that were derived from event data may need a different model in Prometheus. Inventory dashboards by use, drop the ones nobody opens, and rebuild the rest in version-controlled Grafana provisioning files.
Alert conditions and thresholds
Alert conditions and their thresholds are not exported as portable rules. Each one must be rewritten as a Prometheus alerting rule or Grafana alert, and thresholds should be re-validated against a baseline period, not copied. Grafana provisioning and Terraform can hold these rules as code, so a reviewer can see every change before it reaches production.
Notification channels and integrations
Email, chat, paging and ticketing destinations configured in New Relic must be recreated in Alertmanager or Grafana contact points, along with routing, grouping and silences. Alertmanager should be deployed as a cluster for high availability, and Prometheus must point at every Alertmanager instance. Test each route end to end, because a silently broken notification is the most common cutover failure.
Historical telemetry
Historical data in New Relic does not become Prometheus history. Use only the export paths New Relic documents for your account tier, confirm what those paths include and any row or time limits, and store exports as archives. Prometheus begins collecting history on the day it is fed, so plan the parallel run period to build the baseline you need.
Access, users and identity
New Relic user types do not map to Grafana roles one to one, so access must be redesigned rather than copied. Grafana supports LDAP, generic OAuth and Entra ID, Okta and similar providers in all editions, but SAML, team sync and SCIM are limited to Grafana Enterprise and Grafana Cloud. Confirm which identity features you need before choosing an edition.
The migration sequence from inventory to decommission
This sequence moves New Relic telemetry to a self-hosted OpenTelemetry Collector, Prometheus, Jaeger and Grafana one service at a time, while both backends run side by side until each team signs off. It ends with a decommission decision based on what evidence and history the organization needs to keep.
Inventory agents, exporters, dashboards and alerts
The platform or observability lead lists every service that reports to New Relic, including language agents, infrastructure agents, OTLP exporters, log forwarders, dashboards, NRQL queries, alert conditions, notification channels and synthetic checks. Each item is tagged with an owner, a criticality rating and whether it uses OpenTelemetry already or a New Relic-specific agent. The output is a spreadsheet or repository file that maps each signal to its target: Collector, Prometheus, Jaeger, Grafana or a retained commercial tool. The step is done when every production service has an owner and every alert has a named receiver. Teams often find dashboards that nobody has opened for a long time, and those are candidates for retirement rather than rebuilding.
Deploy the self-hosted Collector gateway
The platform team installs the OpenTelemetry Collector, which is Apache-2.0 licensed, as a gateway that receives OTLP over gRPC or HTTP and exports to Prometheus, Jaeger and any remaining backend. Configuration covers receivers, processors such as batching and memory limits, and exporters, with TLS and authentication extensions configured for the environment. The Collector runs in the organization's own cloud account or data center, and the team should confirm the component stability levels in each component's README before enabling anything in production. The output is a running gateway with health checks and its own dashboards. The step is done when test telemetry reaches Prometheus and Jaeger and the Collector's own metrics are visible.
Pilot one service behind the gateway
The team chooses one service with moderate traffic and an engineer willing to test it, then changes the application's OTLP exporter endpoint from the New Relic endpoint to the gateway, or adds a second exporter if it still needs New Relic for comparison. Traces should appear in Jaeger, metrics in Prometheus with a scrape or OTLP receiver path, and logs wherever the organization has chosen to store them. The output is a documented configuration change and a pilot dashboard in Grafana for that service. The step is done when the team confirms span names, service names and key metric labels match what it expects, because NRQL dashboards depend on attribute names that may differ in PromQL.
Run both backends in parallel
For each migrated service, the same OTLP stream is sent to New Relic and to the self-hosted gateway, so the team can compare results over a period it agrees in advance. Engineers rebuild each NRQL dashboard as a Grafana dashboard using PromQL and Jaeger trace views, and recreate alert rules in Grafana alerting with the same thresholds and routing. Prometheus should be treated as reliability-first telemetry, so teams should not expect exact per-request counts for billing or compliance purposes. The output is a side-by-side comparison record for each dashboard and alert, with differences explained. The step is done when the on-call owner has triggered or reviewed test alerts and accepts the self-hosted notifications.
Cut over service by service
Once a service's dashboards and alerts match the agreed comparison, the team removes the New Relic exporter from that service and makes the self-hosted gateway its only telemetry destination. Changes are made through the normal release process with a rollback path that restores the previous exporter configuration. The output is a change record per service and an updated inventory showing New Relic as no longer receiving that service's data. The step is done when the service has run without the New Relic exporter through a full business cycle chosen by the team and no alert gaps have been reported. Teams should repeat this step for each service group rather than switching everything at once.
Decide retention and decommission New Relic
The security, compliance and finance leads decide what historical data must be kept, which may include exports produced with New Relic's own export tooling, dashboards as documentation, and alert histories needed for audits. They confirm the retention period for the self-hosted Prometheus and Jaeger storage, noting that Prometheus local storage is not clustered or replicated by default and that long-term storage may need a separate system. The contract owner then confirms the New Relic termination date with the vendor and removes agents and API keys. The output is a signed decommission record listing retained data, its location and its owner. The step is done when no production service sends data to New Relic, the archive is verified, and the record is filed with the change management system.
How a dual-export Collector pipeline keeps both backends fed
Place one OpenTelemetry Collector between your applications and both backends, so each service sends OTLP once and the Collector fans the same data out to New Relic's OTLP endpoint, to Prometheus and to Jaeger. Applications keep their existing exporter settings, and only the destination changes. Decide placement first. An agent Collector runs beside each host or pod and handles local buffering and retries, while a gateway Collector is a central tier that receives from many sources and holds the exporter credentials. For a parallel run, a small gateway tier is usually easier to audit than credentials spread across every host, though you should confirm the sizing with a load test in your own environment.
Treat the exporter credentials as the main trust boundary. The Collector's authenticator extensions can check who is allowed to send telemetry on incoming receivers, for example with OIDC, and the oauth2client extension can attach credentials to outbound exporter requests. Keep the New Relic license key and any Prometheus or Jaeger credentials in the gateway configuration or a secrets store, never in application code, and restrict which teams can change the pipeline. Review the Collector configuration best practices before exposing the receiver beyond your cluster network.
Prometheus needs the most planning in this design. Its local time series storage is not clustered or replicated and should be run like any single-node database, so a single instance is a single point of failure for metrics and its default 15-day retention is a deliberate choice, not a given. Decide whether Prometheus receives OTLP directly through its OTLP receiver or through remote write, and plan for a second instance or long-term storage if the parallel period must survive node loss. Confirm the chosen Collector and Prometheus versions against the current release lists before you pin them.
How the migration differs by starting point
Teams that instrumented their services with OpenTelemetry SDKs and export over OTLP have the shortest path. New Relic accepts OTLP natively, so the application code already produces traces, metrics and logs in a standard format. The work moves to the export layer: you point the exporter at a self-hosted OpenTelemetry Collector instead of, or alongside, New Relic's OTLP endpoint. The Collector can then fan telemetry out to Prometheus for metrics and Jaeger for traces, which makes parallel running straightforward.
- Exporter configuration: Changes are usually limited to endpoint, headers and resource attributes in environment variables or Collector settings, not to application logic.
- Parallel export: A Collector pipeline can send the same data to New Relic and to the self-hosted backends during the overlap period.
- Attribute naming: Confirm that service names, resource attributes and span names match what your Grafana dashboards and queries will expect.
- Authentication: Use Collector authenticator extensions where the receiving endpoint needs credentials, and keep API keys out of version control.
- Version pinning: Pin SDK and Collector versions so a rolling upgrade does not change telemetry shape mid-migration.
Before you start, check the SDK maturity for each language in your estate, since log signal support varies more than traces and metrics.
Teams running New Relic's language agents have more work. Those agents instrument code automatically and send data in New Relic's own formats, so there is no OpenTelemetry instrumentation to re-point. You must add OpenTelemetry SDKs or auto-instrumentation to each service, then verify that the new spans, metrics and logs cover what the agent captured. The effort depends on how many services run agents, which frameworks they use, and how much custom instrumentation the agents currently enable.
- Coverage gaps: Compare transactions, external calls, database spans and error capture against the agent's output, service by service.
- Agent removal: Remove New Relic agents only after the OpenTelemetry replacement reports the same key transactions in a test environment.
- Custom instrumentation: Calls made through New Relic API methods need equivalent OpenTelemetry spans or metrics.
- Runtime changes: Agent and SDK changes often require application restarts, so schedule them with application owners.
- Service dependencies: Trace context propagation must work across services that are still on the agent and those that have moved, or traces will break at the boundary.
Ask each application owner to list the New Relic features they rely on, because those lists drive the instrumentation backlog more reliably than a count of services.
Organizations with extensive NRQL dashboards and many alert policies face the largest rebuild, whatever their instrumentation method. Re-pointing telemetry does not move dashboards or alerts, and no automated converter from NRQL to PromQL exists. Each dashboard query, facet and alert condition must be rewritten by hand in PromQL or LogQL and rebuilt in Grafana, then validated against the same data. Teams with long-established alert policies also need to decide which alerts still matter before rebuilding them.
- Inventory: Export a list of dashboards, alert conditions, notification channels and their owners from New Relic before any rebuild begins.
- Rationalization: Retire alerts nobody acts on, and merge duplicates, so the rebuild covers only the signals that matter.
- Query translation: Expect NRQL functions such as faceting and percentile aggregations to need a different approach in PromQL, and test results against historical data.
- Notification routing: Rebuild routing and escalation through Alertmanager and Grafana contact points, and confirm which teams receive which alerts.
- Ownership: Assign a named owner for each rebuilt dashboard so ongoing changes do not drift from the new source.
Before committing to a timeline, ask for the inventory size and the count of alert policies in your account, since both drive the rebuild effort more than instrumentation does.
What drives the cost and duration of the migration
This table lists the factors that change the one-time effort and the recurring running cost of moving from New Relic to a self-hosted Grafana and Prometheus stack. Read each row as a question to answer in your own environment before you ask a partner or vendor for a quote.
| Driver | Why it changes cost or effort | How to keep it down or what to ask for |
|---|---|---|
| Services and instrumentation | Each service already sending OTLP needs only an endpoint change, while services on New Relic-specific agents need OpenTelemetry instrumentation first. | Ask for an inventory split by agent type and by language. Confirm which languages have stable trace SDKs. |
| Dashboards and alert conditions | Every NRQL dashboard and alert condition is rebuilt by hand in Grafana, since no automated converter is documented. | Count dashboards and conditions, then group them by owner. Retire unused ones before the rebuild starts. |
| NRQL complexity | Joins, faceting and custom attributes translate to PromQL or other query languages with varying effort. | Ask the partner to classify queries as simple, moderate or complex and to name which need redesign. |
| Log scope | Logs need a separate path through the Collector and a log backend, so the scope of log migration changes the total effort. | Decide whether logs move in this project or in a sibling migration. Quote traces and metrics separately from logs. |
| Retention and storage design | Prometheus local storage defaults to 15 days and is not clustered or replicated, so longer retention usually means remote write to external long-term storage such as Grafana Mimir. | Set retention by data class first. Ask for sizing based on your sample rate and cardinality, not on New Relic ingest figures. |
| Prometheus and Grafana HA design | Grafana HA needs two or more active-active servers behind a load balancer on MySQL 8.0 or later or PostgreSQL 12 or later, since SQLite does not scale for production. Prometheus needs a planned pair or more of scrapers. | Confirm the database, load balancer and alert deduplication design in writing. Ask what is included in the initial build and what is extra. |
| SSO requirements | Grafana's authentication docs list SAML, team sync and SCIM as Enterprise and Grafana Cloud features, while LDAP and OAuth work in every edition. | Confirm the identity provider and protocol now. If SAML is mandatory, price Grafana Enterprise licensing as a separate line. |
| Length of parallel run | Running both New Relic and the new stack keeps two bills and two sets of alerts active until the cutover criteria are met. | Agree cutover criteria and the parallel period length in the written scope. Ask what New Relic costs continue during that window. |
| Recurring operations and upgrades | Grafana ships minor releases every other month and patch releases at least monthly, and each minor release is supported for 9 months. Prometheus minor releases stop receiving fixes after 6 weeks. | Budget staff time for upgrade testing on a fixed cadence. Ask whether the quote includes ongoing upgrades or a retainer. |
What usually goes wrong and how to prevent it
Most failed migrations from New Relic to a self-hosted Grafana and Prometheus stack fail in predictable places: naming, storage assumptions, alert routing, rollback and security defaults. Each card below names one failure, why it matters for this move, and the check that prevents it before cutover.
Metric names and labels break alerts
New Relic data and OTLP metrics that pass through Prometheus can arrive with different metric names, units and attribute-to-label mappings than the NRQL queries assume. Alert rules written against the old names can silently return no data. Before cutover, compare every alert expression against live series from the Collector, and confirm how resource attributes become labels so cardinality stays under control. Check each alert returns data in the parallel run.
Prometheus is not lossless storage
Prometheus is designed to favor reliability over precision, and its docs say it is not suitable where every sample must be exact, such as per-request billing. Local storage is also single-node and not replicated, and default retention is 15 days. Teams used to New Relic retention may discover gaps in long-term history. Decide which data goes to remote write storage, and set retention by time or size deliberately.
Alertmanager reached through a load balancer
Alertmanager can run as a cluster for high availability, but Prometheus must be configured to send alerts to every Alertmanager instance rather than to a load balancer in front of them. Pointing Prometheus at a single balanced address can drop notifications when one node fails. Verify the Alertmanager list in the Prometheus configuration, then fire a test alert and confirm it reaches the on-call channel from each instance path.
Duplicate notifications in Grafana HA
Running two or more active-active Grafana servers behind a load balancer gives high availability, but the Grafana docs note that alerting needs extra configuration to avoid duplicate notifications. Teams that copy New Relic alert conditions without this step may page the same engineer twice. Confirm the alerting HA settings in a staging cluster, and check that Grafana Live features your dashboards rely on are acceptable under HA limitations.
Rollback that was never tested
Cutover plans often assume New Relic can be re-enabled in minutes, but the OTLP exporters, API keys and alert policies may have drifted during the parallel run. A rollback path that has not been exercised may fail under pressure. Keep the New Relic exporter configuration in version control, document who approves the switch back, and rehearse reverting one non-critical service before the main cutover.
Grafana security hardening skipped
A default Grafana installation can expose its version to unauthenticated users, leave the metrics endpoint open and run without the cookie and Content Security Policy settings the vendor recommends. Dashboards often hold credentials, internal hostnames and business metrics. Work through the security hardening guidance, require authentication for metrics, and confirm that identity provider integration matches your access policy, since SAML and SCIM are limited to Enterprise and Cloud.
Questions buyers ask before moving from New Relic
How long does a migration from New Relic to Grafana and Prometheus take?
The duration depends mainly on how many services send telemetry to New Relic, how many dashboards and alert conditions must be rebuilt, and how much of the instrumentation already uses OpenTelemetry. No duration is fixed in advance. Teams with a small number of services and a short list of alerts can move faster than teams with dozens of services, custom NRQL dashboards and alerts tied to on-call processes. Ask for the scope to be split into phases (collector, metrics, traces, dashboards, alerts, cutover) so each one has its own written deliverable and timeline before work starts. Most engagements are fixed-scope, so the timeline is agreed in writing before work begins.
Can our own team run this migration without outside help?
Often yes, if the team already operates Kubernetes or Linux servers, has someone comfortable with PromQL and Grafana provisioning, and can own the alert rules. The work is mostly configuration and rebuilding dashboards rather than new software development. The harder parts are running a stateful backend (Prometheus keeps local storage that is not clustered or replicated), designing high availability for Grafana, and validating that alerts fire the same way they did before. Decide early which of these skills are in-house and which you want to buy as fixed-scope work or a retainer for ongoing support and upgrades.
What does the migration require from our engineers and operators?
Plan for time from three groups: application owners who confirm which services emit telemetry and which OTLP endpoint they use, platform engineers who deploy the OpenTelemetry Collector, Prometheus, Jaeger and Grafana, and on-call or SRE staff who review every alert before it is switched off in New Relic. Each group needs access to the current New Relic configuration, a list of dashboards and alert conditions, and a test environment. Ask your implementation partner to document which owner signs off each deliverable.
Do we have to rewrite our OpenTelemetry instrumentation?
Usually not. New Relic documents native OTLP ingest and recommends it as the preferred route for OpenTelemetry data, so applications already instrumented with OpenTelemetry generally only need their exporter endpoint changed to point at a self-hosted OpenTelemetry Collector. The Collector then forwards metrics to Prometheus and traces to Jaeger. Applications still using New Relic's own language agents are a different case, because those agents must be replaced with OpenTelemetry SDKs or auto-instrumentation before the data can be sent elsewhere. Inventory each service to see which group it falls into and confirm the exporter settings with your New Relic documentation.
Does historical New Relic data move to Prometheus or Grafana?
Not automatically. Re-pointing instrumentation only sends new telemetry to the self-hosted stack, so historical data stays in New Relic for the time you keep the account. If you need old data for audits, trend analysis or incident reviews, decide which datasets matter and export them before the subscription ends. Exporting from New Relic has its own requirements, so check the export options and their limits for your account tier before planning. Prometheus defaults to 15 days of local retention, so longer history requires configuring remote write to external long-term storage, which is a separate design decision.
What runs in parallel with New Relic, and for how long?
During a parallel run, the same OpenTelemetry data is sent to both New Relic and the self-hosted stack, which is possible because New Relic, Datadog and Dynatrace all document OTLP ingestion. Keep both running until dashboards, alert conditions and on-call routes have been checked against the same incidents in both systems. The length of the overlap is a decision to agree in writing, based on your release cycle and the number of alerts to verify. Remember that parallel sending increases New Relic ingest, so measure data volume during the overlap because it affects the bill.
Do we need Grafana Enterprise to use single sign-on?
Not for every provider. According to the Grafana authentication docs, all editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your identity provider requires SAML or you need SCIM user provisioning, budget for an Enterprise license, whose pricing you should request directly from Grafana Labs. Confirm which login method your identity team uses before choosing an edition.
How DeployOpen scopes, runs and supports this migration
DeployOpen, a Chainscore Labs company, plans and implements self-hosted open-source monitoring inside your own cloud accounts, data centers or air-gapped networks. For this migration we start by inventorying the OTLP instrumentation already sending to New Relic, then build, test, document and hand over the Collector, Prometheus, Jaeger and Grafana stack under a written, fixed scope.
How we scope
- Inventory which services already export OTLP to New Relic, and which still rely on New Relic agents.
- List the NRQL dashboards and alert conditions in scope, and agree which ones are rebuilt in Grafana.
- Confirm in writing the parallel-run period, cutover criteria and the retention targets for Prometheus and Jaeger.
How we build
- Deploy OpenTelemetry Collector agents and gateways in your environment, with exporters to Prometheus and Jaeger.
- Rebuild dashboards and alert rules in Grafana, provisioned from files so they are version controlled.
- Test that both backends receive the same telemetry during the parallel run before any cutover is approved.
How we hand over
- Document the Collector configuration, Prometheus storage sizing, Grafana data sources and alert routing.
- Provide a dashboard and alert mapping that shows each New Relic item and its Grafana replacement.
- Walk your operations team through upgrades, backups and the security hardening settings applied to Grafana.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask for a written quote that separates one-time migration work from recurring support and hosting effort.
