Self-Hosted Observability Directory

Migration playbook

Replace New Relic with OSS APM

A migration plan for teams replacing New Relic APM, logs, infrastructure metrics, and dashboards with OpenTelemetry-native tooling.

Vendor New Relic
Timeline 6-10 weeks
Difficulty Medium-high

New Relic migrations usually succeed or fail on instrumentation consistency. Make OpenTelemetry the contract, not the selected UI. That keeps the migration reversible while teams learn the new tools.

Recommended OSS Stack

Stack Options

APM-centered OpenTelemetry stack

Best for: Application teams that care most about traces, service maps, and request-level diagnostics.

SigNoz · Uptrace · OpenTelemetry Collector

  • Keeps developers close to APM workflows, but infrastructure views may need companion tools.
  • OpenTelemetry instrumentation quality determines how complete the experience feels.

Metrics and logs first

Best for: Platform teams whose New Relic usage is mostly infra dashboards, alerts, and log search.

Prometheus · Grafana · Grafana Loki · OpenTelemetry Collector

  • Operationally familiar for Kubernetes teams, but less APM-native out of the box.
  • Requires explicit trace backend selection if distributed tracing is important.

Migration Phases

  1. Map New Relic entities

    1 week

    Outcome: Services, dashboards, workloads, alerts, and synthetics are grouped by owner and business importance.

    • Export entity, dashboard, alert policy, and workload inventories.
    • Mark services that already emit OpenTelemetry or Prometheus metrics.
    • Identify synthetics and browser/RUM usage that needs a separate plan.

  2. Instrument with OpenTelemetry

    2-3 weeks

    Outcome: A collector pipeline receives traces, logs, and metrics from priority services.

    • Introduce OpenTelemetry SDKs or auto-instrumentation for the top services.
    • Route telemetry through collectors so vendor-specific exporters can be swapped safely.
    • Normalize service names, environments, and deployment attributes.

  3. Recreate APM workflows

    2-3 weeks

    Outcome: Developers can answer latency, error, throughput, and dependency questions in the OSS stack.

    • Build RED dashboards for each critical service.
    • Verify trace sampling still preserves error and high-latency requests.
    • Move alert policies from New Relic to Prometheus rules or the chosen APM tool.

  4. Retire New Relic surfaces

    1-3 weeks

    Outcome: Default links, runbooks, and team habits point to the replacement stack.

    • Redirect service docs and incident templates to new dashboards.
    • Freeze New Relic dashboard edits during the final validation window.
    • Reduce ingestion or seats only after team owners acknowledge coverage.

Cutover Checklist

  • Top services emit consistent OpenTelemetry resource attributes.
  • Latency, error, throughput, and saturation views exist for each critical service.
  • Alert routing is tested outside New Relic.
  • Trace sampling policy preserves incident-grade detail.
  • Runbooks no longer depend on New Relic-only links.

Risks To Manage

  • Auto-instrumentation can produce noisy spans or inconsistent service naming without conventions.
  • New Relic synthetics and browser monitoring may require a separate replacement track.
  • Teams may keep using New Relic if documentation and incident templates are not updated.

Back to migration playbooks