Migrate from Datadog to SigNoz: what the move involves
The move is mainly re-instrumentation plus rebuilding dashboards and alerts. Datadog holds the agent, the library instrumentation, the dashboards and the monitors, and none of those carry over automatically into SigNoz. Your application telemetry has to be re-emitted through OpenTelemetry, the SigNoz OpenTelemetry Collector has to receive it, and each Datadog dashboard and monitor has to be rebuilt in SigNoz's Query Builder, PromQL or ClickHouse SQL. Dashboard JSON can be translated with SigNoz's migration tooling, but the output is a starting point that someone must check against the original panels and queries. Renewal or per-host cost pressure usually triggers the project, but the work itself is engineering time, not a license switch.
Platform or SRE engineers usually lead the work, with application teams changing instrumentation in their own services and a security reviewer checking the new ingest path. The security reviewer should look at where the Collector listens, how it authenticates senders (the Collector supports authenticator extensions, including OIDC for incoming connections), how exporters add credentials, and where ClickHouse and the SigNoz API server are placed. Ask the platform team to confirm which SigNoz deployment model fits your residency and operating constraints: Docker Standalone, Docker Swarm or Kubernetes with Helm are all documented for self-hosting, and in that model your team runs storage, scaling, upgrades and backups.
The main risks are gaps in coverage and parallel running. Confirm, service by service, that traces, metrics, logs and custom tags that existed in Datadog reach SigNoz with equivalent attributes, and that alert thresholds fire in the same conditions. Run both backends in parallel for long enough to compare alert behavior, and plan for the overlap cost of two sets of ingest and storage during that window. Use the SigNoz migration guide for Datadog as the first read, and ask your implementation partner for a written scope that lists each dashboard, monitor and integration to be moved, along with who signs off on each.
Which Datadog capabilities map to SigNoz and which need rework
This table maps the main Datadog capabilities to their SigNoz equivalents and marks each as clean, needs rework or gap. Read the status column first, then the notes, to see where cutover effort will concentrate. Most APM, trace, log and alerting work carries over, while SAML, prebuilt integrations and some Datadog-specific dashboard features need planning.
| Datadog capability | SigNoz equivalent | Status and notes |
|---|---|---|
| APM and distributed tracing | SigNoz APM and tracing, fed by OpenTelemetry SDKs | Needs rework: replace dd-trace libraries with OpenTelemetry instrumentation and confirm span attributes used in Datadog monitors |
| Infrastructure metrics | Metrics in ClickHouse via the OpenTelemetry Collector, with host metrics receivers | Needs rework: replace the Datadog Agent with Collector receivers and confirm metric names and tags match existing dashboards |
| Log management | Log management fed by OpenTelemetry log pipelines or the Collector Datadog receiver | Needs rework: rebuild parsing pipelines and saved views, and confirm retention against your storage budget |
| Dashboards | Dashboards built with Query Builder, PromQL or ClickHouse SQL | Needs rework: Datadog dashboard JSON must be translated with SigNoz's migration tool, and some widgets may need manual rebuilds |
| Alerting and monitors | SigNoz alerts with Alertmanager for deduplication, grouping and notification | Needs rework: recreate each Datadog monitor as a SigNoz alert and retest thresholds and notification routes |
| Community Edition scope | Community Edition covers APM, tracing, logs, infrastructure monitoring and alerting | Clean for core observability: confirm these features cover your current use before planning the rest |
| Single sign-on | SSO on every plan, SAML on Teams and Enterprise only | Gap for SAML on Community Edition: confirm whether your identity provider needs SAML or can use another SSO method |
| Prebuilt integrations | Not included in the Community Edition | Gap: rebuild integrations you rely on through OpenTelemetry receivers or custom configuration, and confirm each one with SigNoz |
| Compliance attestations | Community Edition does not include SOC 2 or HIPAA compliance | Gap: request the current compliance documentation from SigNoz and plan your own evidence for any assessment |
What data and configuration can leave Datadog
Not everything in a Datadog account moves the same way. Dashboard definitions and log history have documented export routes, while metrics and traces generally do not, so the migration plan has to treat each data type separately. Confirm each path in your own account before you commit to a cutover date.
Dashboard definitions as JSON
Dashboard definitions can be read as JSON through the Datadog API, which gives you a copy of each layout, widget and query. Treat that JSON as a reference rather than a finished artifact, because widget queries, template variables and formulas must be checked after they are rebuilt. Use the JSON as the source of truth for what each dashboard was meant to show. Export every dashboard you intend to keep, including ones owned by former team members, and store the files in version control before any changes are made.
Translating dashboards with SigNoz tooling
SigNoz documents a migration path from Datadog that includes a dashboard conversion step, so exported dashboard JSON can be translated into SigNoz dashboard definitions instead of being rebuilt entirely by hand. Expect the translation to cover common widget types more reliably than custom formulas or unusual query functions. Check each converted panel against the original query, and confirm in the SigNoz migration guide which Datadog features the converter supports in your version.
Log history from Log Archives
Datadog Log Archives can write logs to an object storage bucket you own, in compressed JSON, so historical log data can remain available after you leave the platform. Set up the archive to a bucket in your own account, confirm the retention rules you need, and check that the storage location meets your data residency requirements. Re-ingesting archived logs into SigNoz is a separate project, so plan that work and its cost explicitly.
Metrics and traces have no bulk export
Datadog does not offer a bulk export for metrics or traces, so historical time series and trace data usually cannot be carried into SigNoz. Plan for a cutover where new data starts flowing into SigNoz while Datadog remains readable for the retention window you need. Ask Datadog in writing which metric and trace history you can still query after the cutover, and record any gaps that auditors or incident reviewers will need to know about.
Monitors and alert definitions
Monitor definitions are not part of a bulk export path in the same way as dashboards, so you will usually recreate them as SigNoz alerts from documented thresholds, queries and notification routes. Export the monitor list through the API where possible, then map each monitor to its SigNoz equivalent and record which ones are retired. Confirm the notification channels and downtime schedules you rely on before you turn off the Datadog monitors.
Confirming each path in your account
Export behavior depends on your Datadog site, plan, API permissions and the archive configuration in your account. Test each path on a non-production dashboard, a sample archive and a single monitor before you rely on it. Record the results, the owner of each export and the date it was run, so the migration evidence can be reviewed later. Ask your Datadog account team to confirm any limit you find.
Migration sequence from inventory to Datadog decommission
This sequence moves Datadog telemetry to self-hosted SigNoz in stages, so each service is proven on SigNoz before its Datadog monitoring is switched off. It ends only when the Datadog Agent and the Datadog account are retired with signed-off evidence.
Build the inventory register
List every host, service, container and function that sends data to Datadog, along with its Agent integrations, custom metrics, log pipelines, APM services, dashboards, monitors and notification routes. Assign an owner to each line and tag it with the team that depends on it. The step is done when the register covers every Datadog source your team can export, and owners have confirmed their entries. Dashboard definitions can be exported as JSON through the Datadog API, and the Datadog documentation on OpenTelemetry describes which Agent features map to OpenTelemetry, so use both as checks against the register.
Classify items by migration path
Sort each register entry into one of three paths: re-instrument with OpenTelemetry, bridge through the Collector's Datadog receiver, or rebuild by hand in SigNoz. Mark items that have no direct equivalent, such as Datadog-only integrations or monitors with features SigNoz does not offer, and assign each a decision owner. The output is a classified register with a short list of gaps that need a written decision before cutover. Confirm integration coverage and any feature differences against the SigNoz migration documentation and your own environment, since not every Datadog integration has a prebuilt SigNoz counterpart.
Instrument a pilot service with OpenTelemetry
Choose one low-risk service with clear ownership and replace its Datadog tracing library with an OpenTelemetry SDK. Run an OpenTelemetry Collector in front of a self-hosted SigNoz installation and export traces, metrics and logs to it. Use the self-host installation guides for Docker, Swarm or Kubernetes that fit your platform. The step closes with a pilot signal checklist: trace spans with the expected service name and resource attributes, metrics with the expected labels, logs with trace correlation, and error rates that match what Datadog shows for the same period. Only move on when the engineering owner has signed the checklist.
Run a parallel period with the Datadog receiver
Keep existing Datadog Agents running and route their traffic through a Collector that uses the Datadog receiver, so the same telemetry reaches SigNoz while Datadog continues to receive it. Compare dashboards, service maps, error counts and alert behavior between the two systems for each service in the migration wave. Record every mismatch in a discrepancy log with its cause and fix. Keep the Collector configuration under version control and review it against the Collector configuration best practices for secure settings. The step is complete when discrepancies are resolved or accepted in writing by the service owner.
Sign off the alert parity list
Recreate each Datadog monitor that the team relies on as a SigNoz alert rule, and link each rule to the same notification channel and escalation path. For every monitor, record the Datadog definition, the SigNoz equivalent, the test that proves it fires, and whether it is paging or informational. Have the on-call owner and the service owner sign the parity list before anyone silences the Datadog original. This list is the main evidence that alerting did not regress during cutover.
Cut over service by service
Move services to SigNoz one at a time, starting with the pilot and continuing in the waves defined in the classified register. For each service, switch its telemetry to the OpenTelemetry path, mute the Datadog monitors that the parity list replaced, and confirm that SigNoz dashboards and alerts are the source of truth. Keep a rollback path, such as re-enabling the Datadog Agent route, until the owner closes the cutover record. Each closed record lists the service, the date and the owner who accepted it.
Decommission agents and the Datadog account
After every wave has a closed cutover record, remove the Datadog Agents from hosts and containers, revoke API and application keys, and remove Datadog integrations from configuration management. Export any dashboards, monitors and logs you need to keep as archived JSON or files in your own storage before you close the account. Confirm billing and contract end dates with Datadog in writing, and ask them what data they retain after closure and how they delete it. The sequence is complete when no active Datadog keys remain, the archive is verified and the account closure is confirmed in writing.
How to run Datadog and SigNoz side by side
Run both backends in parallel by sending the same OpenTelemetry telemetry to Datadog and to SigNoz until the comparison shows SigNoz covers what your teams rely on. The usual approach is a standard OpenTelemetry Collector pipeline with two exporters: one to Datadog over OTLP, and one to your self-hosted SigNoz collector. Datadog documents OTLP ingestion, so services instrumented with OpenTelemetry can feed both sides without code changes per backend. Services still running the Datadog Agent need a different bridge. The Collector's Datadog receiver can accept that older agent traffic and forward it to SigNoz, so hosts can move in batches while the Agent stays in place. Before relying on it, confirm which Agent payloads and features the receiver handles in your Collector version, and read the SigNoz guide to migrating from Datadog for the documented path.
During overlap, compare three things for each service. First, signal presence: confirm that traces, logs and metrics for the same service arrive in both backends over the same window. Second, tags and service names: Datadog tags such as env, service and version must map to the matching OpenTelemetry resource attributes, or one service will appear as two in SigNoz and dashboards will split. Third, alert firing behavior: the same threshold can fire at different times because of evaluation intervals, aggregation windows and notification grouping. Record each firing in both systems over a fixed period, and mute one set of notifications so on-call does not receive every page twice. Decide in advance which system is authoritative for paging.
Dual running has its own cost. Datadog bills per host, APM and per GB or event for as long as it stays active, so the overlap extends those charges. Self-hosting SigNoz adds Collector gateway compute, the SigNoz services and ClickHouse storage, all carried by your infrastructure budget. Staff time is often the largest item: someone must maintain two pipelines, reconcile signals and sign off on alert parity. Before cutover, agree a written end date for the overlap, confirm the notice period and renewal terms in your Datadog contract, and size the SigNoz side from measured ingest volumes rather than assumptions. If you choose SigNoz Cloud instead, its published plan rates apply in place of your own infrastructure costs.
How the migration differs by starting point
Teams whose Datadog use centers on APM and distributed tracing usually have the shortest path to SigNoz, because SigNoz is built around traces, metrics and logs in one application and the instrumentation work is the largest piece. The sequence starts with the services, not the dashboards. Libraries and the Datadog tracer are replaced with OpenTelemetry SDKs, and the Collector can receive the Datadog trace format during cutover so services do not all need to change on the same day.
- Instrumentation first: list every service that sends traces, its language, and whether it uses the Datadog tracing library or an auto-instrumentation package.
- Bridge during cutover: use the Collector's Datadog receiver so traffic from services not yet converted still reaches the new backend.
- Compare trace views: check service maps, latency and error views in SigNoz against the same services in Datadog before retiring the old path.
- Confirm trace features: check sampling, span tagging and retention against what your team relies on, since those settings depend on your own configuration.
Before switching off Datadog APM for any service, confirm with an on-call engineer that the traces they use during an incident appear in SigNoz with the attributes they filter on.
Teams with many custom metrics and large dashboard estates carry the most rebuild work. Custom metric names, tags and dashboard queries are where most of the translation effort sits. SigNoz's migration tooling can help convert dashboard JSON, but converted dashboards still need review because each panel query has to point at data that SigNoz actually receives under the same names and tags.
- Inventory metrics by use: separate metrics used in dashboards and monitors from metrics sent but never read, and rebuild only the first group.
- Normalize names and tags: decide whether to keep Datadog-style names or adopt OpenTelemetry semantic conventions, and apply the choice consistently in the Collector.
- Convert dashboards in batches: export dashboard JSON, run the converter on a small group first, and review each panel's query and units.
- Plan for cardinality: tag sprawl that was tolerable under per-host billing can become a storage and query problem, so review high-cardinality tags before dual-shipping.
Ask whether any dashboards depend on Datadog-specific query functions, since those need manual rewrites in SigNoz's Query Builder, PromQL or ClickHouse SQL.
Teams that send logs to Datadog and keep history through Log Archives in their own object storage have a separate track. Log Archives already place compressed JSON in a bucket the organization controls, so historical logs do not need to move into SigNoz to stay available. The decision is whether new logs flow into SigNoz, which keeps logs next to traces and metrics, or whether logs go elsewhere, such as a dedicated log platform.
- Separate live and archived logs: confirm that archived history stays in your bucket and is readable without Datadog access.
- Decide the live destination: route new logs through the OpenTelemetry Collector to SigNoz, or to another log store, and document the choice.
- Match retention to need: SigNoz retention is set in your own deployment, so decide history length in storage terms rather than inheriting Datadog's settings.
- Keep correlation fields: check that trace IDs and service names in logs match the fields SigNoz uses to link logs to traces.
Confirm with your compliance owner whether archived logs must remain queryable for an audit period, because that decides whether the archive needs its own query tooling.
Teams running the Datadog Agent with many integrations, such as databases, message queues, cloud services and web servers, face the widest inventory. Each integration produces metrics and checks that may have no direct equivalent in SigNoz, so the scope changes from migrating telemetry to deciding which signals still matter. The sequence is driven by the Agent's footprint, not by the APM services.
- Map each integration: for every enabled check, record the metrics it produces, the owner who relies on them, and an OpenTelemetry receiver or exporter that could collect the same data.
- Replace the Agent deliberately: run the OpenTelemetry Collector alongside the Agent for one host group before removing the Agent from the rest.
- Accept gaps: SigNoz's pricing page lists prebuilt integrations as a Community Edition exclusion, so plan to write or configure collection for those sources yourself.
- Retire checks in order: remove low-value checks first and keep a list of anything that alerts someone today.
Confirm with your platform team which integrations have no OpenTelemetry collector component in the version you deploy, since coverage varies by component.
What drives migration cost and duration
This table lists the main cost and effort drivers for moving from Datadog to self-hosted SigNoz, with the reason each one moves cost and how to keep it down. Read it as a checklist to scope a fixed-price quote, since the largest variables are usually instrumentation work and the number of dashboards and monitors. Confirm each figure with your own inventory before you commit to a timeline.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Instrumentation work per language | Each service that uses a Datadog tracing library or the Datadog Agent needs OpenTelemetry SDK or Collector changes, and effort differs by language and framework. | Inventory services by language, start with the highest-traffic ones, and reuse one OpenTelemetry configuration pattern across teams. |
| Dashboard and monitor count | Each dashboard must be converted or rebuilt, and each monitor must be recreated as a SigNoz alert with its notification routing and thresholds. | Export Datadog dashboard JSON, retire unused dashboards first, and group similar monitors into shared templates. |
| Number of integrations to rebuild | Datadog integrations and their tags, metrics and checks do not carry over automatically, so each one needs an equivalent OpenTelemetry receiver or configuration. | List integrations in use from Datadog, then confirm receiver coverage in the Collector before scheduling work. |
| Self-hosting infrastructure | SigNoz self-hosting runs on Docker Standalone, Docker Swarm or Kubernetes with Helm, so you pay for compute and the platform team that operates it. | Choose the deployment model your team already runs, and reuse existing cluster tooling and Helm pipelines where possible. |
| ClickHouse storage and retention sizing | Telemetry is written to ClickHouse, so storage cost follows ingest volume and the retention period you set for logs, traces and metrics. | Measure current Datadog ingest by signal, set retention per signal, and review volumes after the first weeks of dual-running. |
| Dual-running period | Sending telemetry to Datadog and SigNoz in parallel means paying for both platforms until you can confirm parity and cut over. | Define the parity checks in advance, and end dual-running as soon as dashboards and alerts match on the agreed signals. |
| Collector bridge during cutover | Using the Collector's Datadog receiver to bridge services adds configuration, testing and an extra component to secure and operate until retired. | Set a removal date for the bridge at project start, and track which services still depend on it. |
| Staff time and skills | Platform, SRE and application teams spend time on instrumentation, alert review, runbook updates and training, and the work is largely one-time. | Assign owners per service, pair platform staff with application teams, and document alert changes as they happen. |
| Deployment option (Cloud, BYOC or enterprise) | SigNoz Cloud Teams, BYOC and self-hosted enterprise options price differently: Teams starts at $49 a month (SigNoz pricing page), Enterprise starts at $4,000 a month (SigNoz pricing page), and the customer runs infrastructure in the self-hosted enterprise case. | Ask SigNoz for current terms for each option and compare them with the self-hosting staff and storage costs in your own model. |
What usually goes wrong and how to prevent it
Most failed Datadog-to-SigNoz migrations fail at the seams: telemetry that arrives without the names and tags dashboards depend on, alerts that stop firing unnoticed, and support assumptions that do not match the Community Edition. The cards below cover each risk with a check to run before you cut over, so the team can decide what is ready and what is not.
Missing tags and service names
Datadog dashboards and monitors filter on tags such as service, env and version. If OpenTelemetry resource attributes or the Collector's processors do not set the same names, panels go empty without an error. For illustrative purposes, a checkout dashboard filtered on env:prod may show no data while the SigNoz service still receives traffic under a different name. Before cutover, compare the attribute set Datadog reports for each service with what the SigNoz side receives, and fix the mapping in the Collector configuration.
Alert gaps after cutover
Monitors do not convert automatically, so an alert that existed in Datadog may simply not exist in SigNoz on the day traffic moves. Thresholds, evaluation windows and notification routes also change meaning between platforms. Keep Datadog monitors active during dual running, build an inventory of every monitor with its owner, and require a test alert to reach each on-call channel before the Datadog monitor is disabled.
Uneven log SDK maturity
OpenTelemetry trace APIs and SDKs are stable in most languages, but log SDK maturity varies, and several languages are still in development. If your services rely on OpenTelemetry for logs, a language with an immature log SDK may need a different shipping path. Check the status page for each runtime in your estate, pilot the log pipeline on one service per language, and confirm that trace correlation fields arrive in SigNoz before expanding.
Mixed Collector component stability
Core Collector components carry different stability levels, and each component's README states its level. A receiver or processor you adopt at a beta level may change between releases, which can break a pipeline that worked in testing. Pin the Collector distribution version, list every component in the pipeline with its stability level, and read release notes before each upgrade. Releases ship with signed artifacts, checksums and SBOM files, which helps with verification during upgrades.
SAML missing from Community Edition
The free Community Edition supports SSO but not SAML, and SAML is available only on the Teams and Enterprise plans. If your identity provider or security policy requires SAML for console access, the Community Edition will not meet it. Confirm the access requirement with your identity team before choosing self-hosting, and if SAML is required, price the Teams or Enterprise option as an explicit decision rather than an assumption.
No commercial support in Community Edition
The Community Edition's support is community Slack only, so there is no contracted response path when a collector pipeline or ClickHouse node fails during an incident. Decide before cutover who owns the on-call response for the observability stack, whether that is your team, a retained partner, or SigNoz Enterprise support. Write the escalation path into the runbook and test it in a drill before Datadog is retired.
Questions buyers ask before migrating from Datadog to SigNoz
What drives the cost of moving from Datadog to self-hosted SigNoz?
The cost splits into one-time work and recurring running costs. One-time work covers replacing Datadog agents and libraries with OpenTelemetry, rebuilding dashboards and monitors, and dual-running both platforms during cutover. Recurring costs cover the servers or Kubernetes capacity for SigNoz, the ClickHouse storage that holds your telemetry, backups, upgrades and the staff who operate the stack. Storage and retention are the biggest variables, because they grow with the volume of logs, traces and metrics you keep. Ask any partner for a quote that lists each component separately, including who pays for infrastructure, who runs upgrades and what happens during the parallel period. Compare that with your current Datadog invoice line by line, since host, APM and per-GB log charges all reflect different volumes.
How long does a Datadog to SigNoz migration take?
The duration depends mainly on how many services, languages, dashboards and monitors you run, and on how much of your Datadog setup is custom. Teams with a small, well-documented estate usually move faster than teams with many services that use Datadog-specific integrations or tags. Work typically runs in phases: inventory, instrumentation with OpenTelemetry, a parallel run where both backends receive data, dashboard and alert rebuilds, then cutover and decommissioning. SigNoz documents a Datadog migration path that uses the Collector's Datadog receiver during cutover, which can shorten the bridge period but still needs validation. Ask for a phased plan with exit criteria for each phase, and confirm the timeline against your own service inventory rather than a generic estimate.
What does the internal team need to provide for the migration?
Your team supplies the knowledge of how the business uses monitoring, and access to the systems being instrumented. In practice that means an inventory of services and hosts, the languages and frameworks in use, the Datadog dashboards, monitors, notification routes and on-call rules, and the people who own each service. You also need a named owner for production changes, access to the Kubernetes or Docker hosts where SigNoz will run, and a decision on retention periods and who may view sensitive telemetry. Plan time for application teams to change instrumentation, because replacing the Datadog libraries is a code change in each service. Confirm these responsibilities in the written scope before work starts.
Can our own engineers migrate from Datadog to SigNoz without a partner?
Yes, a capable platform or SRE team can do the migration in-house, and SigNoz publishes documentation for Datadog migration and self-hosting. The questions to answer honestly are capacity and skills. Someone must own the self-hosted ClickHouse cluster, backups, scaling, upgrades and security hardening after go-live, because the SigNoz Community Edition has community Slack support only. Rebuilding dashboards and alerts also takes time that competes with feature work. A partner is most useful when the team lacks run experience with ClickHouse or Kubernetes, or when a fixed deadline applies. Whichever route you choose, write down who operates the platform after cutover.
What is the difference between the MIT core and the enterprise code in SigNoz?
SigNoz is open core. Code outside the ee/ and cmd/enterprise/ directories is licensed under MIT, while code inside those directories is under a separate enterprise license in ee/LICENSE. Your legal team should read both license files and confirm how the terms apply to the version and features you plan to deploy. The Community Edition covers APM and tracing, log management, infrastructure monitoring, alerting and LLM monitoring. Features such as SAML, SOC 2 or HIPAA compliance support, anomaly detection and prebuilt integrations are not in the free edition according to the SigNoz pricing page, so check them against your requirements before you commit. Review the SigNoz LICENSE file with counsel.
Should we self-host SigNoz or use SigNoz Cloud?
The choice comes down to who runs the infrastructure and where the data must sit. SigNoz Cloud is the managed option, with a Teams plan that starts at $49 a month including $49 of usage, and data centers in the US, EU and India, according to the SigNoz pricing page. Its usage charges for logs and traces and for metrics are set out on that page, so model your expected volume and retention before comparing. Self-hosting removes the usage charges but moves compute, storage, scaling, upgrades and backups onto your team. SigNoz Enterprise can also be self-hosted with enterprise support, or run as BYOC in your cloud account, which the pricing page lists as options. Ask which deployment keeps telemetry under your control for your regulatory context.
What does a fixed-scope DeployOpen engagement cover for this migration?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope. A written scope typically defines the services to instrument, the SigNoz deployment model, the Datadog dashboards and monitors to rebuild, the cutover approach, the documentation handed over and any post-go-live support. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the agreed scope. Ask for the deliverables, acceptance criteria and exclusions in writing, including how Datadog-specific features that do not map cleanly will be handled.
What breaks most often when moving alerts and dashboards to SigNoz?
Most breakage comes from differences in how alerts and queries are expressed, not from the data itself. Datadog monitors often rely on Datadog tags, notification handles and query functions that have no one-to-one equivalent. SigNoz dashboards can be built with its Query Builder, PromQL or ClickHouse SQL, so you need to decide which query language each panel will use. SigNoz documents a dashboard conversion path, but converted dashboards still need review of units, thresholds, variables and time windows. Check that alerts route to the same on-call tools, test each alert with a known fault, and keep the Datadog definitions exported as a reference until the new alerts have proven themselves.
How DeployOpen scopes and runs a Datadog to SigNoz migration
DeployOpen plans and implements self-hosted SigNoz inside your own infrastructure, then moves Datadog traffic, dashboards and alerts across in stages that keep current monitoring running. Engagements are fixed-scope, so the agreed boundaries, deliverables and timelines are written down before any cutover work starts.
How we scope
- Inventory the Datadog Agents, APM libraries, log pipelines, dashboards and monitors that are in scope for the move
- Confirm where SigNoz will run (Docker, Swarm or Kubernetes) and where its ClickHouse storage and retention will sit
- Agree in writing which features are needed, such as SAML, which the free Community Edition does not include
How we build
- Replace Datadog Agent and tracer dependencies with OpenTelemetry instrumentation and Collector pipelines in your environment
- Configure the Collector Datadog receiver for a bridge period so existing signals reach both platforms during cutover
- Translate exported dashboard JSON with SigNoz's migration tooling, then rebuild and test monitors as SigNoz alert rules
How we hand over
- Document the Collector configuration, SigNoz deployment, alert rules and dashboard mapping for your operations team
- Record which Datadog monitors were retired, replaced or left in place, with the reason for each decision
- Walk your engineers through running upgrades, backups and access controls on the self-hosted SigNoz stack
How we support
- Ongoing support, upgrades and continuous monitoring checks are available as a retainer after handover
- Scope changes for additional services or dashboards are priced and agreed in writing before the work begins
- Ask for a written quote that lists the scope, deliverables, responsibilities and the timeline for each phase
