Which open-source alternative to New Relic fits your team
If your renewal is coming up and you want an all-in-one backend that accepts the OpenTelemetry data you already send, SigNoz is the closest fit. If you want to self-host each layer separately, pick Grafana with Prometheus and Jaeger, which keeps metrics, traces and dashboards as independent components you can swap later. If your main pain is infrastructure monitoring, such as hosts, network devices and services that do not emit traces, Zabbix is the better starting point. Most teams that leave New Relic do so for one of three reasons: a per-GB ingest bill that grows with log and trace volume, per-user charges that make broad access expensive, or a residency requirement that the hosted service does not satisfy for their workloads. The billing model explains the pressure. New Relic bills data by GB ingested regardless of type, and it includes 100 GB ingested per month free. Its user types are Basic, Core and Full platform, so the number of people who need access directly affects cost. The Core Compute option offers consumption-based pricing with unlimited users, priced on queries, alerts and API calls rather than on seats. Whether that option fits depends on your query patterns and alert volume, so model your last twelve months of ingest, user counts and API usage against it. Confirm current terms, included volumes and rate details directly with New Relic before you compare, because these terms change. For a self-hosted comparison, the cost is different in kind. Storage, compute, backup and retention become your infrastructure line items, and the people who operate the stack become a recurring cost. Ask any implementation partner for a written breakdown of hosting, licensing (check each component's license, since Grafana and Zabbix moved to AGPL-3.0 and SigNoz has an enterprise directory under a separate license), setup and ongoing operations. Decide early which telemetry you will keep at full fidelity, because retention and sampling choices will drive storage costs more than the choice of tool.
Which open-source option matches New Relic's APM, metrics and infrastructure
New Relic covers APM, metrics, logs and infrastructure in one hosted product, so no single open-source project replaces all of it. The three options below split that scope differently: one OpenTelemetry-native observability platform, a composable Prometheus and Grafana stack with Jaeger for traces, and Zabbix for infrastructure monitoring. Choose by which part of New Relic your team uses most.
SigNoz as an all-in-one platform
SigNoz is an OpenTelemetry-native observability platform that stores traces, metrics and logs in one product, which is the closest match to New Relic's single-pane model. Its core code outside the ee/ and cmd/enterprise/ directories is MIT, but code inside those directories sits under a separate enterprise license, so check which features your plan depends on before standardizing. Confirm storage sizing, query performance at your ingest volume, and upgrade procedures with the project before production. Your existing OTLP exporters should point at it with little change.
Grafana, Prometheus and Jaeger stack
This option splits New Relic's functions across specialized projects: Prometheus for metrics and PromQL alerting, Jaeger for distributed tracing, and Grafana for dashboards. Prometheus is Apache-2.0 and Jaeger is Apache-2.0 and a CNCF graduated project, while Grafana moved to AGPL-3.0-only starting with Grafana 8.0, which matters if you modify and host it for others. Expect to operate three systems and plan long-term metric retention separately, since it needs its own storage layer. Dashboards and alerts must be rebuilt rather than imported.
Zabbix for infrastructure monitoring
Zabbix is a mature self-hosted monitoring platform aimed at servers, network devices, and host-level metrics, rather than request-level APM. Versions up to 6.4 are GPL-2.0, while Zabbix 7.0 and later are AGPL-3.0, so confirm the license obligations that apply to your version and any modifications. Zabbix sells technical support subscriptions, which is a recurring cost to weigh against internal staffing. Use it to replace host and infrastructure alerting, and pair it with an OpenTelemetry or Prometheus option for application traces.
How New Relic's core capabilities map to self-hosted tools
This table maps each core New Relic capability to the self-hosted tool that covers it, with notes on where coverage is partial. Read the coverage notes before committing, because the strongest equivalents are for metrics and traces, while infrastructure and proprietary add-ons need separate confirmation. The main takeaway is that a migration is usually several tools working together, not one drop-in replacement.
| Capability | Self-hosted option | Coverage note |
|---|---|---|
| APM traces | SigNoz or Jaeger, fed by OpenTelemetry SDKs and Collector | Existing OTLP instrumentation can be repointed. Jaeger v2 is built on OpenTelemetry Collector components. Confirm span search and service map depth for your workloads. |
| Metrics | Prometheus, with Mimir for long-term storage | Prometheus receives OTLP metrics at /api/v1/otlp/v1/metrics when started with --web.enable-otlp-receiver. Plan retention and cardinality separately. |
| Logs | SigNoz, or Loki with Grafana | Log pipelines are often rebuilt, not repointed. Confirm OTLP log ingest and parsing rules for each source before cutover. |
| Dashboards | Grafana | Grafana dashboards must be rebuilt from New Relic NRQL queries. Expect manual translation and a review pass with each service owner. |
| Alerting | Prometheus Alertmanager, Grafana alerting, or SigNoz alerts | Alert rules, routing and notification integrations must be recreated and tested. Confirm escalation and on-call integrations you rely on. |
| Infrastructure monitoring | Zabbix, or Prometheus with node exporters | Zabbix covers infrastructure monitoring rather than distributed tracing. Zabbix 7.0 and later are AGPL-3.0, while earlier versions remain GPL-2.0. |
| User access and per-user billing | Grafana, SigNoz and Zabbix user and role models | New Relic bills by user type. Self-hosted access is governed by each tool's role model, so map roles and SSO requirements before migration. |
| Proprietary add-ons (applied intelligence, synthetic monitoring) | No direct equivalent confirmed in this mapping | Confirm with New Relic which features you use and whether they are in your plan. Plan for separate open-source probes or a manual replacement. |
Reusing OTLP instrumentation already pointed at New Relic
The fastest way to start leaving New Relic without re-instrumenting every service is to keep the OpenTelemetry signals you already emit and point a second destination at a self-hosted backend. New Relic documents native OTLP ingest over gRPC or HTTP on ports 443, 4317 and 4318, and recommends it as the preferred route for OpenTelemetry data. If your services already send traces, metrics and logs through the OpenTelemetry SDKs or Collector to New Relic, the telemetry itself is portable. OpenTelemetry is a vendor-neutral CNCF framework that exports to tools such as Jaeger and Prometheus, so the same instrumentation can feed a self-hosted stack while New Relic remains in place. That is the main reason the migration can be staged, one service or environment at a time.
The practical pattern is an OpenTelemetry Collector fan-out. Run a Collector between applications and backends, receive OTLP once, and export to both New Relic and the new backend through separate exporters in the same pipeline. Before you cut over, run the two destinations side by side and compare the output. Check that service.name and other resource attributes match what your dashboards and alerts expect, since a renamed attribute silently breaks queries. Confirm metric names and units, because Prometheus applies its own naming and suffix conventions when it receives OTLP metrics at its OTLP endpoint, and histograms may need attention. Verify that trace context propagates end to end, so that spans from services that call each other still join into one trace in the new backend. Ask each backend's team to confirm which OTLP fields it maps and which it drops.
Fan-out also has a cost that the New Relic bill will not show. The Collector is a component you operate, so someone must size it, patch it, monitor its queues and decide what happens when a backend is slow. Plan for the period when both destinations receive full volume, because New Relic bills by GB ingested, and duplicate export roughly doubles that ingest during the overlap. Decide in advance which signals must be dual-shipped and which can be turned off early, and document the exit date for each New Relic exporter. Confirm with your New Relic account team how the free ingest allowance and your committed terms apply while the pipeline is running in parallel.
Which option fits your situation: cost, residency or customization
New Relic bills by GB ingested regardless of data type and includes 100 GB ingested per month free, according to New Relic's pricing and billing documentation. Teams whose cost problem comes from high trace, log or metric volume usually gain the most from self-hosting, because the main recurring cost moves from a per-GB subscription to the compute and storage you run yourself. SigNoz is a common first evaluation for trace and log heavy workloads because it is OpenTelemetry-native and can replace a single backend. Grafana with Prometheus, Mimir and Jaeger suits teams that want to tune retention and storage tier by signal type.
- Storage and retention: Your recurring cost is driven mainly by how much data you keep and for how long, so retention policy is the first lever.
- Labor: Operating the stack, upgrades and on-call are one-time setup and recurring staff time, and they are often the largest line item.
- Sampling: Tail sampling and metric cardinality limits reduce volume before it reaches storage.
- Licensing of the stack: SigNoz is MIT outside its enterprise directories, while Grafana and Mimir are AGPL-3.0-only, so confirm which license terms apply to your use.
- Support contracts: Vendor support subscriptions are optional but recurring.
Ask any implementation partner for a quote that separates infrastructure, storage, setup and recurring operations, and confirm your current monthly ingest by signal type first.
Residency requirements often push teams away from hosted backends that store telemetry in a fixed region. Self-hosting lets you decide where every trace, log and metric lands, including inside your own VPC, a data center or an air-gapped network. Grafana with Prometheus and Jaeger, or SigNoz, can run entirely inside the boundary you define. Datadog's hosted sites are independent and data cannot be shared across them, which is a useful reference point when you map where telemetry must stay.
- Placement: Decide whether telemetry, dashboards and query logs must stay in one jurisdiction, and whether vendor support staff may access them.
- Egress: Confirm that OTLP exporters and collectors do not send data to a default external endpoint.
- Backups: Replicated storage and offsite backups can move data outside the boundary even when the primary stays inside it.
- Identity: Single sign-on and user directories may sit outside the boundary and need their own review.
- Ongoing access: Remote support sessions are a residency question, not only a hosting one.
Confirm with your legal and compliance owners which data classes fall under the requirement before choosing a deployment model.
Teams that already run Prometheus and Grafana often need less new tooling than they expect. Prometheus scrapes metrics over HTTP, queries them with PromQL and can receive OTLP metrics at /api/v1/otlp/v1/metrics when started with --web.enable-otlp-receiver. Grafana provides the dashboards and alerting, and Jaeger covers tracing. The migration effort is mostly rebuilding New Relic dashboards and alert rules in PromQL and Grafana, which is a known, bounded task for these teams.
- Query translation: NRQL queries must be rewritten as PromQL or Grafana queries, and some views will not map one to one.
- Cardinality: High-cardinality labels that were cheap in a hosted tool can overwhelm a self-managed Prometheus.
- Long-term storage: Local Prometheus retention is limited, so decide whether Mimir or another long-term store is needed.
- Alert parity: Rebuild and test each alert, including notification routing and escalation.
- Traces: Jaeger or SigNoz still needs its own setup and retention plan.
Confirm the number of dashboards and alerts to rebuild, and check which metrics your current instrumentation already emits through OTLP.
If most of your monitoring is hosts, network devices, databases and availability checks rather than application traces, Zabbix may fit better than an APM-first platform. Zabbix covers infrastructure monitoring, problem detection and alerting in one self-hosted system. Be aware that Zabbix was relicensed from GPL-2.0 to AGPL-3.0 starting with Zabbix 7.0 in 2024, while versions up to 6.4 remain GPL-2.0, so license review is part of the decision. Zabbix sells technical support subscriptions, which are optional.
- Scope fit: Zabbix is strongest for infrastructure and availability; application tracing usually needs a separate tool.
- Version choice: Compare the license terms of 6.4 and 7.0 or later before standardizing.
- Agent deployment: Confirm how agents will be rolled out and maintained across host fleets.
- Integration: Decide how Zabbix alerts reach your existing incident tooling.
- Scaling: Confirm sizing for your host count and check items per second with your team.
Ask which New Relic infrastructure monitors and alerts are actually in use, since many may be replaced more simply than expected.
Regulated organizations need to show how monitoring controls work, who can change alerts and dashboards, how logs are retained and how access is reviewed. Self-hosting gives you direct control over these records, but it also makes you responsible for producing them. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any audit reports or attestations. The evidence set you need depends on the framework your auditors use, so confirm it early.
- Access control: Document who can view, edit and export telemetry, and how changes to alert rules are approved.
- Audit logging: Confirm the platform records administrative and configuration changes, and where those logs are stored.
- Retention: Set retention periods for telemetry and audit logs that match your policy and framework.
- Change records: Keep version control for dashboards, alert rules and collector configuration.
- Auditor review: Ask the auditor which control evidence they expect from monitoring before design starts.
Confirm with your auditor which frameworks apply and which monitoring evidence they will request before choosing an option.
What running your own observability storage costs compared with New Relic ingest
This table sets New Relic's ingest and user charges against the components you pay for when you self-host, and separates one-time migration work from recurring operating cost. Use it to decide which drivers to model first, then collect quotes and written scopes before comparing totals. New Relic's 100 GB free monthly ingest and Core Compute consumption model are the two billing facts to model against.
| Cost component | Who you pay | One-time or recurring | What drives it up or down |
|---|---|---|---|
| New Relic data ingest | New Relic, per GB ingested | Recurring | Telemetry volume after the 100 GB monthly free allowance, plus logs and traces you keep sending |
| New Relic user licenses or Core Compute | New Relic, per user type or per consumption | Recurring | Number of Basic, Core and Full platform users, or query, alert and API call volume under Core Compute |
| Self-hosted compute for collectors and backends | Cloud provider or data center team | Recurring | Ingest rate, query concurrency and number of collector replicas for Prometheus, Jaeger or SigNoz |
| Storage and retention | Cloud provider or storage team | Recurring | Retention period per signal type and compression; longer retention increases disk and object storage use |
| Metric cardinality and query load | Cloud provider and engineering team | Recurring | Label combinations and dashboard refresh rates; high cardinality raises memory and storage needs |
| Network egress and cross-zone traffic | Cloud provider | Recurring | Where collectors and storage sit relative to workloads; keep telemetry paths in one region where possible |
| Implementation, OTLP pipeline and dashboard rebuild | Internal team or implementation partner, per written scope | One-time | Number of services, existing New Relic dashboards and alerts to recreate, and whether instrumentation is already OTLP |
| Ongoing support, upgrades and internal skills | Internal staff, optional support contract with vendor or partner | Recurring | Team size, on-call expectations, upgrade frequency and whether you buy a support subscription or retainer |
What you give up when you leave New Relic and how teams work around it
Moving off New Relic trades a managed platform for components you run yourself. The cards below cover the operational, analytical and licensing gaps that show up most often, with the workaround teams usually adopt and what to confirm before committing.
Vendor-managed operations
New Relic runs storage, scaling, upgrades and availability for you. A self-hosted stack spreads that work across a collector, a metrics store, a trace store, dashboards and alerting, and each one needs capacity planning and patching. Teams usually assign one owner for the pipeline and write runbooks for ingest backpressure and storage growth. Confirm who on your side holds on-call for the telemetry platform itself, since a monitoring outage during an incident is the failure you can least afford.
In-house on-call and upgrade skills
Running Prometheus, Grafana, Jaeger or SigNoz in production requires people who can tune retention, debug high-cardinality series, and plan version upgrades without losing history. Most teams cover this with one or two named platform engineers and a documented upgrade calendar. Ask your candidate implementation partner for a written scope covering upgrade windows, backup and restore tests, and handover of runbooks, so these skills do not sit with a single person.
Lighter out-of-the-box APM and AI analysis
New Relic's automatic instrumentation, service maps and AI-assisted investigation take less setup than an open stack. With OpenTelemetry, you assemble service maps, error grouping and anomaly detection from separate components, and some of that analysis is not available as a packaged feature. Run a proof of concept against your own traces to find which investigations your engineers rely on today, then confirm in each platform's documentation whether that capability ships or needs custom work.
NRQL queries and New Relic dashboards
Dashboards, alert conditions and saved NRQL queries are tied to New Relic's query language and data model, so they do not carry over unchanged. Teams typically export a list of dashboards and alerts, group them by owner, and rebuild the critical ones in Grafana with PromQL or the query language of the trace backend they choose. Confirm how many alert conditions must be recreated and which ones depend on data New Relic derives rather than data you send.
AGPL obligations for Grafana, Mimir and Zabbix
Grafana, Grafana Mimir and Zabbix from version 7.0 onward are licensed under AGPL-3.0, which requires source availability to users who interact with a modified version over a network. Grafana was relicensed from Apache-2.0 to AGPL-3.0-only, and Zabbix 6.4 and earlier remain GPL-2.0. Ask counsel whether internal-only use changes your obligations, and whether any modifications you plan to make would trigger source disclosure.
SigNoz enterprise code boundary
SigNoz is open core. Code outside the ee/ and cmd/enterprise/ directories is MIT, while code inside those directories sits under a separate enterprise license. Teams that deploy only the community code avoid that license, but any feature they need from the enterprise directories requires a separate agreement. Confirm which features your dashboards and alerts depend on, and check the license terms for those directories before you standardize on SigNoz.
How to move dashboards, alerts and traces off New Relic in stages
This sequence moves New Relic workloads to a self-hosted backend one service at a time, so each step has a checkpoint and the team can roll back before any New Relic agent, key or license is retired.
Inventory agents, exporters, dashboards and users
DeployOpen works with your platform and application teams to list every New Relic agent, OTLP exporter and collector, each dashboard and alert condition, each notification channel, and every user and API key. Your team supplies access to the New Relic account, the service owners, and the list of services that must stay monitored during the move. The step is done when the inventory is signed off by the service owners and each item has a named owner and a target backend.
Confirm which telemetry already uses OTLP
Services already sending OpenTelemetry data to New Relic's OTLP endpoint need only a changed exporter target, while services on classic New Relic agents need instrumentation work first. DeployOpen checks each service and records the signal types (traces, metrics, logs) it emits. Your team confirms which language runtimes and agent versions are in use. The step closes with a list that separates services that can be redirected from services that need re-instrumentation.
Map NRQL queries to the target query language
Each NRQL query behind a dashboard or alert is translated into PromQL for Prometheus metrics, or into the query language of the chosen trace or log backend. Some NRQL functions and event types have no direct equivalent, so DeployOpen flags them for redesign rather than forcing a literal translation. Your team reviews the mapped queries with the owners of the dashboards they serve. The output is a mapping sheet that shows the source query, the target query and any known difference in results.
Pilot the stack on one service
Choose a single, non-critical service and route its telemetry through an OpenTelemetry Collector to the self-hosted backend, for example Prometheus with Grafana for metrics and Jaeger or SigNoz for traces. DeployOpen deploys the collector configuration, the storage and the first dashboards in your environment. Your team confirms that traces appear end to end and that the metrics match what New Relic shows for the same period. The pilot is complete when the service owner signs off on the data and on the rebuilt dashboard.
Run both backends in parallel with dual shipping
The OpenTelemetry Collector exports the same signals to New Relic and to the self-hosted backend at the same time, so both can be compared during normal load. DeployOpen configures the exporters, sets up queue and retry settings, and tracks collector health. Your team watches data volumes and checks that the New Relic ingest stays within the expected range while the self-hosted side is validated. The step closes when every in-scope service has sent data to both sides for a period the team has agreed in writing.
Verify alert parity before cutover
Each New Relic alert condition is recreated as a rule in the target system, and both are evaluated against the same data. DeployOpen records when each rule fires, when it resolves, and where notifications are sent. Your team confirms that thresholds, evaluation windows and on-call routes match, and it decides how any gaps will be covered. The step is done when the parity log shows that every critical alert has a tested equivalent and an approved owner.
Cut over and retire New Relic agents, keys and licenses
Services are switched to send telemetry only to the self-hosted backend, starting with the lowest-risk group, and New Relic ingestion is stopped service by service. After each group runs cleanly, DeployOpen removes New Relic agents and exporter configuration, revokes API and ingest keys, and archives exported dashboards and query definitions. Your team confirms with procurement and the New Relic account owner which user seats and licenses to cancel, and when, under the current contract terms. The step is complete when no New Relic keys are active, the archive is stored, and the access review is closed.
Questions teams ask before replacing New Relic
What drives the cost of replacing New Relic with a self-hosted stack?
The main drivers are ingest volume, retention period, and the engineering time needed to run storage and collectors. New Relic bills by GB ingested regardless of data type and includes 100 GB ingested per month free, according to New Relic's pricing and billing documentation, so the comparison starts with how many GB your teams actually send each month. On the self-hosted side, you pay for compute and disk for storage, network egress, backup, and staff time to operate the stack. Storage grows with retention and cardinality, so longer retention and high-cardinality metrics raise the bill. Ask any partner for a quote that separates one-time setup from recurring infrastructure and support costs, and that states the assumed ingest and retention figures.
How long does a migration off New Relic usually take?
The timeline depends on how many services you instrument, how many dashboards and alerts you rebuild, and how much parallel running you want before cutover. Teams that already use OpenTelemetry can start by sending the same telemetry to both backends, which lets them compare data before switching alert routing. Plan separate work for dashboards, alert rules, on-call routing, and retention decisions for historical data, since old New Relic data usually does not move with the telemetry. No duration applies to every estate, so ask for a timeline in the written scope that lists the services, the cutover order, and the validation steps.
Can our own engineers do the migration without outside help?
Yes, many teams do it in-house, but the work requires skills in OpenTelemetry Collector configuration, Prometheus or another metrics store, trace storage, and Grafana or SigNoz dashboards. Check whether your team has someone who has run a self-hosted monitoring platform in production, since upgrades, retention tuning, and high-availability design are ongoing tasks. A fixed-scope engagement with DeployOpen can cover planning, implementation, integration, hardening, backup, and documentation inside your own cloud account or data center. Compare the internal effort you can spare against the written scope before deciding.
Can we reuse OTLP instrumentation already pointed at New Relic?
In most cases, yes. 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, according to its OpenTelemetry OTLP documentation. Because the instrumentation emits standard OTLP, you can point the exporter at an OpenTelemetry Collector that fans out to your self-hosted backend, such as Jaeger for traces or Prometheus for metrics, while keeping New Relic running in parallel. Confirm that your services use OTLP exporters rather than New Relic's proprietary agents, because agent-based instrumentation will need to be replaced.
What happens to our NRQL dashboards and alerts after migration?
NRQL queries do not run on Grafana, Prometheus or SigNoz, so each dashboard and alert must be rebuilt in the new tool's query language. Prometheus uses PromQL for metrics, Jaeger and SigNoz provide their own trace query interfaces, and Grafana provides dashboards and alerting across several data sources. Export a list of every NRQL dashboard and alert condition, group them by the signal they use, and map each one to an equivalent query. Some alerts will need rethinking rather than direct translation, so validate them against known incidents before retiring the New Relic version.
How do AGPL and enterprise licenses affect internal use of these tools?
Licensing depends on the specific component, so check each one before you deploy it. Grafana was relicensed from Apache-2.0 to AGPL-3.0-only on April 20, 2021, first shipped in Grafana 8.0, and Grafana Mimir is also AGPL-3.0-only, according to Grafana's LICENSING.md. Zabbix moved from GPL-2.0 to AGPL-3.0 starting with Zabbix 7.0, while versions up to 6.4 remain GPL-2.0. SigNoz is open core, with code outside its ee/ and cmd/enterprise/ directories under MIT and code inside those directories under a separate enterprise license. Internal use of AGPL software usually differs from offering it to outside users as a network service, so have your legal team review your intended use against the license text.
What does a fixed-scope engagement with DeployOpen cover?
A fixed-scope engagement covers the work listed in a written scope, including deliverables and timelines agreed before work starts. For this migration, that can include planning the target architecture, implementing the OpenTelemetry Collector and self-hosted backends, integrating with your existing services, hardening, backup, upgrades documentation, and handover. DeployOpen deploys inside your own cloud accounts, data centers, or air-gapped networks. It prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or certifications. Ongoing support, upgrades, and continuous testing are available as retainers. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope.
How DeployOpen scopes and hands over a New Relic replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source monitoring platforms inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. For a New Relic replacement, the work usually splits into four decisions that the written scope must settle before any build starts: which backend receives the OTLP streams that already point at New Relic, whether metrics stay in Prometheus or move to a long-term store, how traces and logs are retained, and who owns the dashboards, alert rules and on-call routing that replace the ones in New Relic. Each decision should name the component, the owner and the acceptance check, for example a dashboard set that is rebuilt and compared against the New Relic originals for an agreed period.
Most engagements are fixed-scope. Scope, deliverables, environments, acceptance criteria and timelines are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list, so the useful preparation on your side is an inventory: the services and OTLP exporters in use, the New Relic user types and retention settings in place, the data volumes you expect to ingest, and any residency or evidence requirements that the platform must meet. Ask any provider to price these items separately, including the one-time build, the hardening and the migration cutover, and the recurring infrastructure and support, so the comparison with New Relic's ingest-based and per-user billing is like for like. Confirm with us and with your own security team which compliance evidence the new platform must produce, since DeployOpen prepares systems and evidence for assessments but independent auditors issue any report.
Handover is where many replacements succeed or fail, so the written scope should include documentation, runbooks, backup and restore tests, and a defined support model. Ongoing support, upgrades and continuous testing are available as a retainer, which suits teams that want an operator for the stack after the initial build without hiring for it in-house. Before signing, ask for the handover deliverables in writing, the upgrade and backup responsibilities for each component, and how a retainer scope changes when your data volumes or services grow. Teams that want to confirm the fit first can start with the inventory and a short written scope, then decide on the build.
