Datadog migration guide

Switch from Datadog to AllStak

A Datadog migration is mostly about untangling per-host, per-GB, and per-product billing — the observability itself maps cleanly. Here is the staged plan.

Why a Datadog migration is simpler than it looks

Teams that switch from Datadog usually are not unhappy with the product — they are unhappy with the invoice. Migrate application instrumentation separately from standard host collection, using Grafana Alloy, OpenTelemetry, or Prometheus exporters.

AllStak covers the core of what most teams actually use in Datadog — error tracking, log management, distributed tracing, uptime, and infrastructure monitoring — in one platform with flat, predictable pricing in SAR or USD. This guide lays out the honest Datadog migration path: what maps directly, what you rebuild by hand, and why you should keep both running for a sprint before you cancel.

Why teams switch from Datadog

The pattern is consistent across teams planning a Datadog migration: the bill, the SKU sprawl, and the region.

Flat pricing instead of per-host and per-GB math

Datadog bills per host, per GB of logs, and per product, so autoscaling or a chatty service moves the invoice. AllStak plans are flat and predictable — you know the cost before the month starts.

One product, not a catalog of SKUs

Errors, logs, traces, uptime, infrastructure, and session replay ship together in AllStak. There is no separate line item to negotiate every time the team wants one more signal.

Saudi data residency and an Arabic dashboard

For KSA and GCC organizations, AllStak offers Saudi data residency, SAR pricing, and a fully bilingual Arabic/English dashboard — an operating fit global vendors do not offer.

How to switch from Datadog, step by step

Six steps, staged so production visibility never drops. The application side moves first; the infrastructure agent can follow host by host.

  1. 1

    Create an AllStak project and copy its DSN

    Create a project, open Get started, and copy its AllStak DSN. The DSN routes official Sentry SDK events to the selected project.

  2. 2

    Disable the Datadog tracer and SDK init

    Remove or disable the dd-trace init and any Datadog client libraries in the service you are migrating first. Leave the Datadog agent running on hosts for now — infrastructure cutover comes after the application side is proven.

  3. 3

    Install the official Sentry SDK for your stack

    Use the maintained official Sentry package for the runtime. For a Node.js service, install @sentry/node and initialize it with the AllStak project DSN.

    terminal
    npm install @sentry/node
  4. 4

    Set release and environment in the init

    Pass release and environment so grouping and deploy tracking work from the first event — the equivalent of Datadog's version and env tags. For browser JavaScript, upload source maps so stack traces stay readable.

    app.ts
    import * as Sentry from '@sentry/node';
    
    Sentry.init({
      dsn: process.env.ALLSTAK_DSN,
      environment: process.env['NODE_ENV'] ?? 'production',
      release: process.env.APP_VERSION,
    });
  5. 5

    Recreate your monitors as notification rules

    Export the list of Datadog monitors that actually page someone, and rebuild those as AllStak notification rules. Slack, email, webhooks, PagerDuty, Opsgenie, and Telegram are supported — and a migration is the perfect excuse to drop the monitors nobody acts on.

  6. 6

    Run both for a sprint, then cancel Datadog

    Keep Datadog collecting in parallel for one sprint. Compare errors, traces, host metrics, and alert behavior, then move remaining hosts to standard collectors before cancelling.

Datadog concepts, mapped to AllStak

The vocabulary changes less than you would expect — use this table when rewriting runbooks.

DatadogAllStak
MonitorsAlert rulesRouted through notification rules to Slack, email, webhooks, PagerDuty, Opsgenie, or Telegram.
APM tracesDistributed tracing
Log ManagementLog managementIncluded in the platform — not billed per GB as a separate product.
InfrastructureInfrastructure monitoring (Linux agent)
Error TrackingError tracking
DashboardsProject dashboards

Datadog migration FAQ

Can I import my historical Datadog data?

No. Historical data stays in Datadog. Fresh application events arrive after the official Sentry SDK uses the AllStak DSN; keep the infrastructure transition separate and staged.

Does AllStak replace the Datadog agent on my hosts?

For Linux hosts, yes: Grafana Alloy, OpenTelemetry, or Prometheus exporters can send CPU, memory, disk, process, and container telemetry into the same platform as your errors and logs. Migrate collectors host by host during the parallel run.

How does AllStak pricing differ from Datadog's?

Datadog prices per host, per GB of ingested logs, and per product. AllStak uses flat plan pricing, in SAR or USD, that covers errors, logs, traces, uptime, and infrastructure together — so scaling hosts or log volume does not produce surprise invoices.

Will I lose any capability by leaving Datadog?

Be honest in your inventory: Datadog's catalog is broader. AllStak covers the core most teams use daily — errors, logs, tracing, uptime, infrastructure, session replay. If a niche Datadog product is load-bearing for you, verify the AllStak equivalent during the parallel sprint before canceling.

Do my Datadog dashboards transfer?

No — dashboards are rebuilt, not imported. AllStak ships project dashboards for errors, requests, logs, and hosts out of the box, so most teams find they recreate far fewer custom dashboards than they had.

Plan your Datadog migration

Start free, move one service, and compare AllStak against Datadog on your own production traffic before you touch the rest of the fleet.