Migrate from New Relic to SigNoz: what the move involves
The move is mostly re-instrumenting or repointing telemetry, then rebuilding dashboards and alert policies by hand. A team facing a New Relic renewal, a pricing change or a data residency requirement should expect no automated converter for dashboards, alert conditions or agent configuration. The work splits into three streams: replacing New Relic APM agents with OpenTelemetry instrumentation or repointing applications that already export OTLP, collecting logs through the OpenTelemetry Collector or Fluent Bit, and recreating every dashboard and alert policy in SigNoz. SigNoz's own migration guide for New Relic is the natural starting inventory, but the rebuild itself is manual work for each service and team.
Platform engineering and SRE usually own the self-hosted SigNoz stack, the Collector gateway, ClickHouse storage and the Alertmanager configuration. Application teams own the instrumentation changes in their services, since agent swaps touch build files, runtime settings and deployment manifests. Some organizations hand the stack build, hardening and backup design to an implementation partner such as DeployOpen, and keep an internal team for application changes. Either way, agree in writing who maintains the Collector configuration after cutover, because that file becomes the single point where data routing, sampling and credentials are controlled.
Risk is highest in alerting and in the parallel-run period. An alert that fires in New Relic but has no equivalent in SigNoz is a silent gap, so map every New Relic alert condition to a SigNoz rule and confirm the notification path before turning anything off. Run both backends in parallel for long enough to compare signals for each critical service, and keep an export of existing New Relic data if your audit or retention rules require it (see the separate guidance on exporting New Relic data). Confirm with SigNoz which features your chosen edition includes, since the free Community Edition leaves out SAML, SOC 2 and HIPAA compliance support and relies on community Slack for help.
Which New Relic capabilities map cleanly to SigNoz
This table maps the main New Relic capabilities to their SigNoz equivalents and marks each row as clean, needs rework or gap. Read the status column first, then check each gap against your own compliance and feature requirements, since the free Community Edition differs from paid plans.
| Capability | SigNoz equivalent | Status |
|---|---|---|
| APM and distributed tracing | SigNoz APM and tracing built on OpenTelemetry traces, included in Community Edition | Needs rework: New Relic agents must be replaced or traces re-sent via OpenTelemetry |
| OTLP ingest | Native OpenTelemetry ingestion through the SigNoz OpenTelemetry Collector | Clean: existing OTLP exporters can be repointed to the self-hosted endpoint |
| Log management | Log collection and search in Community Edition, fed by the OpenTelemetry Collector or Fluent Bit | Needs rework: forwarders and parsing rules must be rebuilt and checked |
| Infrastructure metrics | Infrastructure monitoring in Community Edition, using OpenTelemetry host and container metrics | Needs rework: New Relic infrastructure agent coverage must be mapped host by host |
| Dashboards | Dashboards built with the Query Builder, PromQL or ClickHouse SQL | Needs rework: NRQL dashboards must be recreated by hand, with no automated converter |
| Alerting | Alerting with Alertmanager for deduplication, grouping and notification | Needs rework: alert policies and conditions must be recreated and tested |
| User access and SSO | SSO is listed on every plan, including Community Edition | Clean: confirm your identity provider setup against the plan you choose |
| SAML, SOC 2 and HIPAA compliance | Not included in Community Edition, available on Teams and Enterprise plans for SAML | Gap: confirm with SigNoz which plan and attestations meet your requirements |
How OTLP exporters and New Relic agents change during the move
The first decision is which of two situations you are in, because they change the work very differently. New Relic documents native OTLP ingest and recommends it as the preferred way to send OpenTelemetry data, over gRPC or HTTP on ports 443, 4317 and 4318. If your services already export OTLP to New Relic, the migration is mainly an endpoint change: point the exporters at the SigNoz OpenTelemetry Collector, confirm the Collector's receivers and authentication match your network policy, and keep the New Relic exporter in place during a parallel run. If your services use New Relic language agents instead, each agent has to be replaced with OpenTelemetry instrumentation, either the SDK with manual spans or the auto-instrumentation for your runtime. Inventory every service by agent type before you schedule any cutover, since the two paths have different owners and test plans.
Before you commit to OpenTelemetry instrumentation in a given language, check that language's status on the OpenTelemetry status page. Trace APIs and SDKs are stable in most languages, including Go, Java, Python, .NET and JavaScript, but log SDK maturity varies more and several languages still have log SDKs in development. Plan logs separately from traces and metrics: a service can be migrated for tracing while its logs continue to ship through your existing forwarder. Also confirm the stability level of each Collector component you rely on, since core components have mixed stability levels documented in their READMEs. Ask your SigNoz or implementation contact to name the exact receivers, processors and exporters in your pipeline so these checks can be done per component.
On the backend side, SigNoz writes telemetry through its OpenTelemetry Collector into ClickHouse, a column-oriented database, while an API server serves the frontend and query APIs. Your operators therefore need to understand ClickHouse sizing, storage and backup before go-live, because those tasks replace what New Relic ran for you. Trace and metric ingest will reach the Collector first, so size its capacity and check the query paths your dashboards will use. Confirm with SigNoz which deployment method fits your environment, Docker Standalone, Docker Swarm or Kubernetes with Helm, and which parts of ClickHouse operation your team will own.
What data and configuration can be moved
A New Relic to SigNoz move splits into two groups: what you can carry over with OpenTelemetry, and what you must rebuild by hand. No automated converter exists for dashboards or alert policies, and the telemetry history itself needs a separate export check with New Relic before you plan any backfill. Work through each card as an inventory line item with an owner and a sign-off.
Historical telemetry data
Traces, metrics and logs already stored in New Relic are a separate question from the new pipeline. Ask New Relic in writing which export paths your account and plan support, and what format and time window they cover, before you promise anyone a history in SigNoz. Until that answer is confirmed, plan for SigNoz to start receiving data at cutover, and keep New Relic read access for the retention period your compliance team needs.
Dashboards and queries
NRQL dashboards have no automated converter to SigNoz. Each widget must be rebuilt in the SigNoz Query Builder, PromQL or ClickHouse SQL, so inventory every dashboard, its owner and its audience, then retire the ones nobody has opened. Prioritize the operational views used during incidents, because those are the ones on-call engineers will reach for first.
Alert policies and conditions
New Relic alert policies, conditions, thresholds and muting rules do not transfer automatically. Recreate each one in SigNoz alerting, then compare the thresholds and evaluation windows against the New Relic version so behavior stays the same. Record which alerts were deliberately dropped, because an undocumented drop looks like a missing alert during the first real incident.
Notification channels and routing
Email, chat, paging and webhook destinations configured in New Relic must be re-entered in SigNoz, which uses Alertmanager for deduplication, grouping and notification. Confirm each destination still exists, rotate any integration keys that were tied to a former team member, and test each route with a non-production alert. Escalation paths that rely on an external on-call tool need the same review.
Users, roles and SSO
New Relic user types and role assignments have no direct equivalent to copy across. SigNoz lists SSO on every plan, including Community, while SAML is available only on the Teams and Enterprise plans. Map each New Relic role to a SigNoz permission set, confirm which identity provider you will federate with, and remove accounts for people who no longer need access before the cutover.
Collector and agent configuration
Application agents are replaced by OpenTelemetry instrumentation or existing OTLP exporters repointed at a self-hosted OpenTelemetry Collector that writes to SigNoz. Document each receiver, processor and exporter, the authentication method on every receiver, and the endpoint each service uses. Keep the configuration in version control so the parallel-run period and the final cutover can be audited.
Migration sequence from inventory to decommission
This sequence moves New Relic telemetry to self-hosted SigNoz in stages, so each service is proven on OpenTelemetry before its New Relic agent is removed. Each step produces a record that the next step depends on, and the final step closes out New Relic retention and access.
Inventory agents, exporters, services and alerts
The engineering lead and the on-call owners list every service that reports to New Relic, including the agent or OTLP exporter in use, the language and runtime, and the hosts or clusters involved. They also export the dashboards, alert conditions, notification channels and NRQL queries that depend on that data, and note which ones are actually used. The output is a service inventory with a telemetry source, owner and a dependency list for each service. The step is done when every New Relic agent and exporter appears in the inventory and each owner has confirmed their row.
Choose pilot services and confirm SigNoz sizing
Select one or two services with moderate traffic and a named owner, preferably ones that already export OTLP to New Relic, since their telemetry can be sent to both backends with a configuration change. Confirm with SigNoz which deployment path fits your environment (Docker Standalone, Docker Swarm or Kubernetes with Helm) and who will run ClickHouse, storage, upgrades and backups. The output is a pilot scope document and a sign-off checklist covering data retention, access and network paths. The step is done when the platform owner has approved the chosen deployment path in writing.
Send pilot OTLP data to both backends
Instrument the pilot services with OpenTelemetry where they still use a New Relic agent, then route telemetry through an OpenTelemetry Collector that fans out to New Relic's OTLP endpoint and to the self-hosted SigNoz Collector. Where a service already sends OTLP to New Relic, add a second exporter rather than changing the application. Secure the Collector with the authentication and configuration practices in the OpenTelemetry guidance before it receives production traffic. The output is a working dual-export pipeline and a checklist of traces, metrics and logs confirmed in both backends. The step is done when the pilot owner confirms that data arrives in both systems.
Run a parallel comparison of traces, metrics and alerts
Run both backends side by side for the pilot services and compare what each one shows. Check that trace spans, service names, error rates and latency percentiles match within an agreed tolerance, and rebuild the critical alert conditions in SigNoz Alertmanager so they fire on the same test conditions as in New Relic. Record gaps such as missing attributes, label differences and features the Community Edition does not include. The output is a comparison report listing each dashboard and alert with its result and an owner for each gap. The step is done when the pilot owner signs off the report and every gap has a decision: fix, accept or retire.
Migrate logs through the Collector or Fluent Bit
Move log collection for the pilot services to the OpenTelemetry Collector or Fluent Bit, depending on what the team already runs, and send logs to SigNoz. Confirm that log fields are parsed the same way they were in New Relic and that trace identifiers appear on log records so logs can be linked to traces. The output is a log pipeline configuration per service and a set of sample queries that return the same results as before. The step is done when the on-call team can find an error in SigNoz using the same steps they used in New Relic.
Cut over service by service with a rollback plan
Move the remaining services in small groups, starting with those with the lowest risk. For each group, switch the exporter to SigNoz only, keep the New Relic configuration available in version control, and write the rollback steps before the change. Owners watch error rates and alert behavior during the change window and confirm that on-call routing reaches the right people. The output is a cutover record per group, including the rollback plan and the owner's sign-off. The step is done when every service in the inventory reports only to SigNoz and no alert still routes through New Relic.
Decommission New Relic agents and retention
Remove New Relic agents and exporters from application images, startup scripts and infrastructure templates, and revoke the license keys and API keys that they use. Confirm with your New Relic account team which data you need to keep, export it using the supported method in New Relic's documentation, and record what is retained and for how long. Remove the New Relic account from access reviews and close notification channels that still point to former on-call groups. The output is a decommission record listing removed agents, revoked keys, exported data and the retention decision. The step is done when a final check shows no New Relic traffic and the account owner accepts the record.
What drives the cost and duration of the move
This table lists the inputs that change the size of a New Relic to SigNoz move, who is paid for each one, and whether it is one-time or recurring. Use it to build the scope you send for a written quote, and check each row against your own inventory before you commit to a budget.
| Driver | Why it changes cost or effort | What to ask for or confirm |
|---|---|---|
| Services and languages | Each service needs its New Relic agent replaced with OpenTelemetry instrumentation or its OTLP exporter repointed, and effort rises with each language runtime. | Ask the quote to list every service, language and framework, with a count of agent-based and OTLP-based services. |
| Agent versus OTLP mix | Services already sending OTLP need only an endpoint change, while agent-based services need code or configuration work and retesting. | Confirm which services use New Relic language agents and which already export OTLP to New Relic's endpoints. |
| Dashboards and alert policies | New Relic dashboards and alert policies are not converted automatically, so each one is rebuilt by hand in SigNoz and checked against its original behavior. | Request a count of dashboards, alert conditions and notification channels, and a list of which are business critical. |
| Log sources and volume | Each log source needs a collector or Fluent Bit pipeline, parsing rules and field mapping, and volume affects collector sizing and storage. | Ask for the number of log sources, average daily volume and any parsing or redaction rules that must carry over. |
| Retention needs | Longer retention increases ClickHouse storage and the cost of SigNoz Cloud usage, while the Community Edition retention depends on your own disk. | Confirm required retention for traces, logs and metrics, and whether auditors need historical data kept in the new platform. |
| SSO and compliance requirements | SAML is available only on SigNoz Teams and Enterprise plans, and SOC 2 and HIPAA compliance are not included in the Community Edition. | Confirm whether SAML is required, which compliance evidence your auditors expect, and whether it must come from the vendor. |
| Operating ClickHouse and the stack | Self-hosting makes your team responsible for ClickHouse, the Collector, the API server, Alertmanager, upgrades, scaling and backups on an ongoing basis. | Ask the quote to separate one-time setup from recurring operation, and to state who runs upgrades, restores and capacity reviews. |
| Platform cost model | SigNoz Cloud bills usage above its plan, with a Teams plan starting at $49 a month including $49 of usage (SigNoz pricing page), and SigNoz Enterprise starts at $4,000 a month (SigNoz pricing page). | Request a written comparison of self-hosted infrastructure, staff time and support against the hosted or Enterprise options, using your own volumes. |
What usually goes wrong and how to prevent it
Most failed New Relic to SigNoz migrations break quietly rather than loudly. The risks below share one root cause: the old agents and dashboards carried behavior that nobody wrote down, so each cutover needs an explicit inventory and a check against live data.
Gaps in trace and log coverage
Removing a New Relic agent before every service emits OpenTelemetry traces and logs leaves blind spots that look like healthy traffic. Background jobs, queue consumers and services with no instrumentation often disappear first. Build a service inventory from New Relic's entity list, then confirm each service sends spans and log records to SigNoz before its agent is removed. Check that trace context propagates across service boundaries, since broken propagation splits one request into unrelated traces.
Alert policies left unrecreated
New Relic alert conditions, notification channels and incident routing do not move into SigNoz automatically, so a policy can exist in the old account and never be rebuilt. The risk is silence: a service fails and nobody is paged. Export the full list of New Relic conditions, map each one to a SigNoz alert rule and notification target, and record the owner of each. Then trigger a controlled failure for each critical rule to confirm the alert reaches a real on-call channel through Alertmanager.
Unmatched metric names and labels
Metric names and attribute keys often change between New Relic agents and OpenTelemetry instrumentation, so queries and dashboards return empty panels or wrong totals. A rename of a single attribute can break a whole dashboard family. Compare the attribute names emitted by the old and new pipelines for the same request, and decide which names your dashboards will use before rebuilding them. Verify each rebuilt panel against a known value from the New Relic side during the parallel period.
No SAML on Community Edition
The free Community Edition includes APM, log management and alerting, but SAML is available only on the Teams and Enterprise plans, and Community Edition support is through community Slack. Teams that planned SAML-based sign-in for a regulated environment can discover the gap after cutover. Confirm the identity requirements with your security team before choosing an edition, and confirm current feature availability on the pricing page, since plan contents can change.
Undersized ClickHouse storage
SigNoz stores telemetry in ClickHouse, and in a self-hosted deployment your team owns the disk, retention and scaling. Unlike New Relic's hosted ingest, a growing trace or log volume fills local storage without warning, and a full disk stops ingestion. Measure daily volume during the parallel run, size storage for that volume plus the retention you need, and set disk usage alerts well before capacity is reached. Confirm the retention settings for each signal type.
Parallel runs that never end
Sending telemetry to both New Relic and SigNoz is a sound way to compare results, but teams often keep both running indefinitely, which doubles agent overhead and keeps New Relic billing active. Set a named cutover date for each service group, define the comparison checks that must pass before that date, and route duplicate exports through the OpenTelemetry Collector so the old destination can be removed with one configuration change. Record who approves the decommission.
How the migration differs by starting point
Teams already sending OTLP to New Relic have the shortest path, because the application code does not change. The work is in the export configuration and in what sits behind it. New Relic documents native OTLP ingest over gRPC or HTTP on ports 443, 4317 and 4318, so the same telemetry can be routed to a SigNoz OpenTelemetry Collector during a parallel run. Most of the effort moves to dashboards, alerts and retention rules, which have to be rebuilt by hand.
- Endpoint and header changes: Update the exporter endpoint and authentication headers in each service, or route through a central Collector that fans out to both backends.
- Parallel run: Send the same signals to New Relic and SigNoz for a defined period so you can compare trace and metric counts before cutting over.
- Semantic conventions: Check that service names, resource attributes and span names match what your existing dashboards expect.
- Sampling: Confirm where head or tail sampling happens, since it affects how comparable the two backends look.
- Authentication: If the Collector sits at the edge, review its receivers with the authenticator extensions described in the Collector configuration docs.
Ask your team which exporters are in use and whether any service still sends through a New Relic agent before you assume this path applies to the whole estate.
Teams running New Relic language agents have the most instrumentation work. The agents do not send OTLP to SigNoz, so each service needs an OpenTelemetry SDK or auto-instrumentation package added, and the agent removed once data flows. Agent-specific features such as custom attributes, transaction naming and error grouping must be reproduced with OpenTelemetry APIs. Plan this per language, because SDK maturity differs across languages.
- Inventory: List every service, its language and the agent version, and flag services with custom instrumentation.
- Language support: Check the OpenTelemetry status page for trace and metric stability in each language before you commit a service to it.
- Transaction naming: Map New Relic transaction names to OpenTelemetry span names so latency views stay recognizable.
- Rollout order: Start with low-risk services, then move customer-facing ones once dashboards match.
- Agent removal: Remove the New Relic agent only after the replacement has run in production for a period you agree internally.
Confirm with each application owner which custom metrics and error groupings they rely on, because these are the items most often lost in translation.
Teams that forward large volumes of logs to New Relic need a separate track for log collection. The question is whether logs leave through an existing forwarder such as Fluent Bit or through the OpenTelemetry Collector. Per-GB billing makes log volume the main cost driver, so the work includes deciding what is worth keeping and at what retention. Self-hosted storage moves that cost to your own infrastructure, where it depends on the ClickHouse sizing and disk you provision.
- Forwarder inventory: Identify every log source, the forwarder in front of it and the New Relic log parsing rules applied.
- Parsing rules: Recreate grok or parsing logic in the Collector or Fluent Bit, and test it against sample lines.
- Volume review: Measure current daily volume per source so you can size ClickHouse storage and set retention with your own numbers.
- Filtering: Drop low-value debug logs at the edge to reduce storage and query load.
- Parallel forwarding: Duplicate log streams to both backends for the parallel run, then remove the New Relic output.
Ask for the retention period your compliance team requires, because it sets the storage cost more than anything else in this track.
Teams with residency requirements have an extra decision before any agent or exporter changes. SigNoz Cloud offers US, EU and India data centers, and SigNoz Cloud Dedicated or BYOC places a managed deployment in a customer environment. A self-hosted install keeps data in your own data center, but then your team owns infrastructure, storage, scaling, upgrades and backups. Settle the location and operating model first, because it determines whether the Collector and ClickHouse run in your network.
- Deployment model: Compare SigNoz Cloud regions, Dedicated, BYOC and self-hosted against your data handling rules.
- Enterprise support: Note that SigNoz Enterprise starts at $4,000 a month according to SigNoz's pricing page, and that it covers Dedicated, BYOC and self-hosted with enterprise support.
- Community limits: The Community Edition lacks SAML, SOC 2 and HIPAA compliance, so confirm whether those are required before choosing it.
- Collector placement: Keep Collectors in the region where telemetry originates to limit cross-border transfer.
- Evidence: Collect configuration and access records your assessor will ask for, and confirm with them what they accept.
Confirm your residency obligations with legal and compliance before the first pilot, since they decide the architecture.
Questions buyers ask before moving from New Relic to SigNoz
How much effort and time does a move from New Relic to SigNoz take?
The effort depends mostly on how much New Relic-specific instrumentation, dashboards and alert policies the team has built, not on the backend itself. No supplied source gives a standard duration, so treat any timeline as something to agree in writing after a scoping review. The main drivers are the number of services using New Relic agents, the number of log sources, the number of dashboards and alert policies to rebuild by hand, and how many environments must run in parallel before cutover. Ask any implementation partner to break its estimate into those components.
Can our team migrate to SigNoz without outside help?
A team with strong OpenTelemetry and Kubernetes skills can do the move in-house, since SigNoz is documented for Docker Standalone, Docker Swarm and Kubernetes with Helm. Teams without that experience usually find the hard parts are the Collector pipeline design, ClickHouse sizing and retention, and rebuilding alerts with the right routing. DeployOpen plans, implements and documents this work in your own infrastructure under a fixed-scope written agreement, so you can choose to take on all, part or none of it.
What does our side need to provide for the migration?
Plan for access and decisions from your own staff: cloud or data center accounts for the SigNoz deployment, a list of services and their current New Relic agents, log sources, dashboards and alert policies, and named owners who approve changes. You also need a decision on where the self-hosted stack runs and who is on call for it afterward. Ask the implementation partner to list these inputs in the written scope so that delays can be traced to a specific dependency.
Do New Relic dashboards and alert policies convert to SigNoz automatically?
No. There is no automated converter from New Relic to SigNoz, so each dashboard and alert policy must be recreated. NRQL queries have to be rewritten using SigNoz's Query Builder, PromQL or ClickHouse SQL, which are the dashboard query options SigNoz documents. Expect the rebuild to be a manual task with a review step, and keep a list that maps each New Relic dashboard and alert to its SigNoz equivalent so nothing is dropped silently.
Should we run New Relic and SigNoz in parallel during the cutover?
Running both in parallel is usually the safer path. New Relic documents native OTLP ingest on ports 443, 4317 and 4318, and Datadog and Dynatrace also document OTLP ingestion, so instrumenting with OpenTelemetry lets one telemetry stream feed a commercial backend and SigNoz at the same time. The Collector can fan data out to both destinations. Confirm that the New Relic OTLP export is in place for every service before changing the source of truth, and agree a parallel-run period and comparison checks in the scope.
What does the free Community Edition of SigNoz leave out?
According to SigNoz's pricing page, the free self-hosted Community Edition includes APM and tracing, log management, infrastructure monitoring, alerting and LLM monitoring. It does not include SAML, SOC 2 or HIPAA compliance, anomaly detection or prebuilt integrations, and its support is community Slack only. SSO is listed on every plan, including Community. If your organization needs SAML, a compliance attestation or vendor support, confirm those requirements against the Teams or Enterprise plans before you commit. DeployOpen does not issue SOC 2 or HIPAA attestations; independent auditors do.
What does a self-hosted SigNoz Enterprise deployment make our team responsible for?
According to SigNoz's pricing page, in the self-hosted Enterprise option the customer's team runs the infrastructure, storage, scaling, upgrades and backups, with enterprise support on top. The other Enterprise options, Cloud Dedicated and BYOC, shift some of that operating work to SigNoz. The Enterprise starting price is listed on the same page at $4,000 a month. Your own costs would also include compute, ClickHouse storage, retention and staff time, which should be requested as separate line items in any quote.
How DeployOpen scopes and runs the migration
DeployOpen plans and implements the move from New Relic to self-hosted SigNoz inside your own infrastructure, including the OpenTelemetry instrumentation, Collector pipelines and rebuilt dashboards and alerts. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Inventory New Relic agents, OTLP exporters, log forwarders, dashboards and alert policies, and record which ones carry production traffic.
- Agree in writing which services move to OpenTelemetry, which Collector pipelines are built and which dashboards and alerts are rebuilt.
- Confirm where SigNoz will run (Docker, Swarm or Kubernetes), the data residency requirement and the features needed beyond the Community Edition.
How we build
- Instrument services with OpenTelemetry or repoint existing OTLP exporters at a self-hosted Collector and SigNoz backend.
- Configure Collector pipelines for logs and traces, including Fluent Bit or Collector log collection, with authentication on receivers and exporters.
- Rebuild dashboards in the SigNoz Query Builder and alert rules, then test each alert path against notification targets before cutover.
How we hand over
- Run New Relic and SigNoz in parallel for an agreed period, comparing telemetry and alert behavior before switching off the old agents.
- Document the architecture, Collector configuration, dashboard and alert inventory, and the runbooks for ClickHouse storage, upgrades and backups.
- Deliver a cutover checklist and a list of New Relic features that were not carried over, so your team knows the gaps before the contract ends.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan SigNoz version upgrades and Collector updates in your change process, with testing in a non-production environment first.
- Confirm with your team which support model fits, since the free Community Edition offers community Slack support only.
