Other options to evaluate

Alternatives to New Relic

A New Relic replacement needs to preserve the incident workflow, not just collect the same signal types. Inventory agents, OpenTelemetry pipelines, NRQL dashboards, alert conditions, browser monitoring and retention requirements. The best shortlist depends on which parts of that workflow the team wants to operate itself.

Migration starts with requirements

Before changing tools

Export dashboard definitions as a reference, then rebuild the queries and alerts that operators actually use. An exported New Relic dashboard is not a portable query language. Trial one representative service with equivalent sampling, retention and permissions, and compare the result before changing the rest of the estate.

Required agents, OpenTelemetry signals and feature compatibilityNRQL queries, dashboards, alert semantics and incident routingManaged platform versus owned collectors and storageRetention, sampling, access controls and measured billable usage

Use the profile fields below as a starting point, then confirm current capabilities, migration paths, licensing and pricing in the official documentation.

Reproducible proof of concept

Plan the New Relic migration

  1. List instrumented services, New Relic agents, custom attributes, NRQL queries, dashboards, alert policies, notification destinations and retention obligations. Export dashboard JSON as a migration reference.
  2. Select one service and define expected errors, latency percentiles and alert timing. Decide which existing agent features require replacement and which telemetry can use OpenTelemetry.
  3. Run an isolated trial or an explicitly supported dual-export pipeline. Keep sampling consistent, avoid duplicate instrumentation and record the extra telemetry volume during the evaluation.
  4. Recreate the important queries and alerts in the destination. Trigger a known failure and verify signal correlation, permissions, notification delivery and missing-data behavior.
  5. Move services in small batches with a rollback owner. Retain the required historical access, compare observed billable usage and remove old agents or credentials only after cutover is accepted.
Production decision record

Test the change before committing

Migration and rollback

Inventory data, configuration, identities and integrations. Time a representative export, import and rollback before choosing a cutover plan.

Security and operations

Compare access controls, audit logs, update ownership, backup recovery, observability and the work required during an incident.

Total cost

Model licenses, infrastructure, data transfer, support and operator time at production scale. Record plan limits and renewal assumptions.

Read the evaluation methodology · Report a correction

Why these options are different

Technical shortlist

Datadog

Evaluate Datadog for a managed platform with Agent-based integrations and OpenTelemetry ingestion options. Select the instrumentation and collector approach first: supported features differ between Datadog and OpenTelemetry combinations. Rebuild the important monitors and compare telemetry volume using the target configuration.

Limits to confirm

  • Confirm data location, export and exit terms because self-hosting is not recorded.
  • Test API coverage, authentication, rate limits and failure handling.
  • Review license, renewal and portability terms because an open-source license is not recorded.

Dynatrace

Evaluate Dynatrace when OneAgent discovery and instrumentation match the application estate. OpenTelemetry ingestion is also supported, but browser and mobile monitoring need their own capability check. Confirm the offered deployment and edition before assuming that SaaS and Managed provide identical features.

Limits to confirm

  • Self-hosting shifts upgrades, backups and incident response to your team.
  • Test API coverage, authentication, rate limits and failure handling.
  • Review license, renewal and portability terms because an open-source license is not recorded.

Grafana

Evaluate Grafana Cloud when the team wants a managed OTLP destination, or a Grafana-based stack when it can operate the required data backends. Grafana dashboards alone do not replace New Relic collection and storage. Test metric-label mapping, query rewrites and links between logs and traces.

Limits to confirm

  • Self-hosting shifts upgrades, backups and incident response to your team.
  • Test API coverage, authentication, rate limits and failure handling.
  • Confirm the exact license and support boundary for deployed components.

SigNoz

Evaluate SigNoz for an OpenTelemetry-oriented workflow with cloud and self-hosted deployment options. Its New Relic migration documentation separates metrics, traces, logs, dashboards and alerts. For self-hosting, include storage capacity, upgrades and restore testing in the comparison.

Limits to confirm

  • Self-hosting shifts upgrades, backups and incident response to your team.
  • Verify automation requirements because an API is not recorded in the profile.
  • Confirm the exact license and support boundary for deployed components.

Sources reviewed on . Verify current release notes, prices and plan limits before procurement.

Official sources

Keep the current option in the proof of concept

A replacement decision should use the same workloads, failure tests and cost assumptions for every candidate.

Review the New Relic profile →Compare these tools →