Prerequisites

• A self-hosted SigNoz instance — see /datadog/ for the 20-minute docker-compose recipe and ~$20/mo VPS sizing (ClickHouse needs 4GB+ RAM minimum).
• Root or Ansible/Chef/Puppet access on every host running the Datadog Agent (you're swapping a system service).
• If you use Datadog APM via tracer libraries (`ddtrace`, `dd-trace-java`, etc.): familiarity with your application's tracer initialization, since you'll be swapping to OpenTelemetry equivalents (`opentelemetry-instrument` / OTel auto-instrumentation).
• An object store (S3 or compatible) if you want long-term ClickHouse retention — SigNoz can offload cold data.
• A list of your most important Datadog dashboards (top 10 by usage) — these are your first rebuild targets.

Step 1 — Export from Datadog

1. Inventory what Datadog is collecting

   On a Datadog Agent host: `datadog-agent status` lists every check and integration. Save the output. This is your inventory — for each integration (postgresql, nginx, redis, kafka), there is an OTel Collector receiver equivalent.

2. Export dashboard JSON

   For each dashboard you want to rebuild: Datadog → Dashboards → ⋯ → Export Dashboard JSON. Save to a `dashboards/` directory in version control. The JSON is human-readable and shows widgets, queries, and visualizations — which is your spec for the SigNoz/Grafana rebuild.

3. Export monitor (alert) definitions

   Datadog → Monitors → Manage Monitors → ⋯ → Export. JSON dump of all alerts. Same purpose: the source of truth for what you'll recreate as SigNoz alert rules.

4. Decide on historical data

   Datadog's metrics export API exists but is rate-limited and per-metric. For most teams it's not worth the engineering: keep Datadog active for 30 days post-cutover as a read-only archive, then cancel. If retention compliance matters, do a one-off bulk export via the Datadog API and store as Prometheus remote-write into a separate Mimir/Cortex instance — that's a separate project.

Step 2 — Import into SigNoz

5. Stand up SigNoz

   Single-node docker-compose: clone `https://github.com/SigNoz/signoz`, `cd deploy/docker/clickhouse-setup`, `docker compose up -d`. The UI is on port 3301. Default credentials let you create the first admin account on first visit.

6. Configure the OTel Collector receiver address

   Note the SigNoz OTLP endpoint: by default `http://<signoz-host>:4318` (HTTP) or `:4317` (gRPC). This is what your collectors and tracer libraries will point at. If exposed over the internet, terminate TLS at a reverse proxy and use the HTTPS variant.

7. Replace the Datadog Agent on each host

   On each host: `sudo systemctl stop datadog-agent && sudo systemctl disable datadog-agent`. Install the OpenTelemetry Collector (`apt install otelcol-contrib` on Debian/Ubuntu, or the upstream tarball). Drop a config at `/etc/otelcol-contrib/config.yaml` with your prior Datadog integrations as OTel receivers (`hostmetrics`, `postgresql`, `nginx`) and an OTLP exporter pointing at SigNoz. Start: `sudo systemctl enable --now otelcol-contrib`. SigNoz → Services should show the host within 30 seconds.

8. Swap APM tracer libraries to OpenTelemetry

   Per-language work. Python: replace `ddtrace-run python app.py` with `opentelemetry-instrument python app.py` and set `OTEL_EXPORTER_OTLP_ENDPOINT=http://signoz:4318`. Node: replace `dd-trace` import with `@opentelemetry/sdk-node`. Java: replace `dd-java-agent.jar` with `opentelemetry-javaagent.jar`. Same span shapes — service names, operation names — translate without app code changes.

9. Rebuild dashboards in SigNoz

   SigNoz → Dashboards → New Dashboard. For each Datadog widget, the rebuild is: pick the same metric (e.g. `system.cpu.user`), apply the same group-by tag, render the same visualization. SigNoz's query builder is point-and-click; for advanced queries use the ClickHouse SQL mode. Plan a half-day per dashboard if it has 10-20 widgets.

10. Recreate alerts

    SigNoz → Alerts → New Alert. Translate Datadog monitor expressions into SigNoz alert rules. For threshold alerts (`avg(last_5m):avg:system.cpu.user{*} > 80`), the SigNoz form has Metric / Aggregation / Threshold / Window fields that map 1:1. For complex composite monitors, use the PromQL-style query builder.

Field / concept mapping

Downtime estimate

No service downtime — the agent swap is per-host and the apps don't notice. Plan ~2 hours per host for the first few hosts (you'll iterate the OTel Collector config) and 10 minutes per host once you have a reusable Ansible playbook. Allow 2-4 weeks of dual-collection (Datadog + SigNoz running side-by-side) so you can validate dashboards under real production load before cancelling Datadog.

Common gotchas

• Datadog tags are looser than OTel attributes. Tags like `env:prod` translate to `deployment.environment=prod` per OTel semantic conventions — your existing dashboard filters need rewriting.
• Datadog's `dd.service` / `dd.env` / `dd.version` env vars are read by their tracer; OTel uses `OTEL_SERVICE_NAME`, `OTEL_RESOURCE_ATTRIBUTES`. Update your Dockerfiles / Helm charts.
• Datadog's auto-discovery on Kubernetes (annotations like `ad.datadoghq.com/<container>.check_names`) has no OTel equivalent — you configure the OTel Collector with explicit receivers via the Operator pattern instead.
• ClickHouse single-node has a soft ceiling around 50-100k spans/second. If you're at that volume already, plan for a multi-node ClickHouse setup or consider Grafana Mimir/Loki/Tempo instead — operational burden trade-off.
• Datadog dashboards exported as JSON do not import into SigNoz. The JSON is documentation only. Don't build expectations of an automated tool here.

Rollback plan

Reinstall the Datadog Agent and revert tracer libraries (one-line change in Dockerfile). Datadog data is unaffected during the migration since the agent swap is forward-only — you simply resume sending. Keep Datadog billing active for 30-60 days post-cutover so you can flip back if SigNoz shows gaps. Most teams discover the gaps in week 2-3 (a specific dashboard query that doesn't translate); having Datadog still on lets you fix the translation before commit.