New Relic is APM-first, and its pricing, per full-platform user plus data ingest, penalizes exactly what observability should encourage: giving the whole team access. Teams that want broad, un-metered access and predictable cost move to a self-hosted Prometheus core (for metrics), usually paired with OpenTelemetry, Tempo (traces), and Loki/Grafana (logs and dashboards). This guide focuses on the New-Relic-specific angles.
Why teams leave New Relic specifically
Two drivers, distinct from Datadog:
- Per-user seat pricing limits who can log in, counterproductive for a tool everyone should use during incidents. Self-hosting removes seat limits entirely.
- Data-ingest overages stack on top.
If broad team access is your pain point, this move pays off in a way that’s about licensing model, not just raw cost.
What you’re replacing
New Relic is a unified APM/observability suite. Mapping to open components:
- APM / auto-instrumentation → OpenTelemetry auto-instrumentation + Tempo for traces. This is the biggest lift: New Relic’s language agents auto-instrument deeply; you re-instrument with OTel SDKs/agents.
- Infrastructure metrics → Prometheus (
node_exporter, exporters, or OTel). - Dashboards → Grafana.
- Alerts → Prometheus Alertmanager (or Grafana Alerting).
- Logs → Loki.
- NRQL → PromQL / LogQL / TraceQL, a real query-language shift.
A safe migration flow
- Inventory what New Relic does for you: instrumented services, key transactions, dashboards, alert policies, and notification/paging integrations.
- Stand up the stack, Prometheus + Alertmanager + Grafana, plus Tempo and Loki as needed. The
kube-prometheus-stackHelm chart is a common starting point on Kubernetes. - Re-instrument with OpenTelemetry, replace New Relic agents with OTel SDKs/auto-instrumentation, pointing exporters at your collector. Start with your most important services.
- Recreate the essentials, translate critical alert policies into PromQL alerting rules and rebuild the top dashboards in Grafana.
- Dual-run New Relic and the new stack; compare coverage, trace quality, and alert fidelity.
- Cut over paging, then remove New Relic agents and seats.
Re-instrumenting APM with OpenTelemetry
This is the long pole of the migration, so plan it as its own workstream rather than a step. New Relic’s language agents attach deeply and populate transaction traces, service maps, and error analytics with almost no configuration. OpenTelemetry reaches the same place, but you assemble it:
- Enable auto-instrumentation per language. Java, .NET, Python, Node, and others have OTel auto-instrumentation that covers common frameworks and HTTP/DB clients. Turn it on service by service rather than all at once.
- Add manual spans for bespoke code. Anything New Relic inferred from its agent hooks but that OTel does not cover automatically needs explicit spans, so inventory what New Relic was capturing first.
- Run collectors as the pipeline. OTel Collectors receive from the SDKs and export metrics to Prometheus, traces to Tempo, and logs to Loki, giving you one vendor-neutral layer instead of per-vendor agents.
- Tune trace sampling so you keep useful traces without storing every request, which is your decision now rather than the vendor’s.
Confirm traces are captured and correlated for a representative request path before you trust the service on the new stack.
Translating NRQL and alert policies
NRQL was one language over everything; the new stack splits it three ways. Metric conditions become PromQL alerting rules in Alertmanager (or Grafana Alerting), log conditions become LogQL, and trace conditions become TraceQL. The gotchas that catch New Relic teams: PromQL rates need an explicit range window, percentile alerts require a histogram you are actually exporting, and NRQL’s FACET grouping becomes sum by (...) or avg by (...). Re-express the alert policies that page humans first, and validate each fires on a real condition instead of assuming the translation held.
The gaps to plan around
New Relic’s auto-instrumentation and curated APM views are polished; OpenTelemetry gets you there but with more setup, and instrumentation maturity varies by language. Distributed-trace correlation and some APM niceties take effort to match. Budget for OTel pipeline work and PromQL fluency on the on-call team.
Managing storage and cardinality
New Relic’s bill came from seats plus ingest; the self-hosted stack removes both meters but hands you storage and cardinality to manage instead. The instrumentation you add with OpenTelemetry decides how much data lands, so pick trace sampling rates and metric label sets deliberately rather than mirroring everything New Relic collected. High-cardinality labels blow up Prometheus series counts and memory, and verbose traces size Tempo, so treat re-instrumentation as a chance to keep only what on-call reads. For long metric retention, add Thanos or Mimir rather than forcing a single Prometheus to hold months of high-resolution data. The savings are durable when you are disciplined about volume, and eroded when you are not.
What has to pass before you trust it
Fire test alerts end to end, confirm traces are captured and correlated for a representative request path, do a dashboard parity review, and load-test retention. Acceptance bar: the team is paged correctly and can debug a real incident on the new stack.
Our take
New Relic → Prometheus is primarily about escaping per-user pricing and unlocking team-wide access, in exchange for owning an OpenTelemetry-based stack. Metrics and dashboards migrate well; re-instrumenting APM/traces and learning PromQL are the work. Dual-run, prove trace and alert fidelity, then cut over. Model your per-user/ingest savings in the calculator above, and treat them as illustrative until you validate against your real telemetry volume.