How to Migrate from Datadog in 6 Weeks: Dual-Write, Field Mapping, Rollback (2026)

Short answer: A safe Datadog migration has four phases: inventory (every dashboard, monitor, and agent config you actually use), parallel run (dual-write telemetry to both platforms for 2+ weeks), cutover (move alerting and on-call last, not first), and decommission (only after a full billing cycle confirms parity). The mechanics that matter most: instrumentation with OpenTelemetry or ddtrace-compatible collectors makes the data plane portable; dashboards and monitors do not port and must be rebuilt deliberately — which is why the inventory phase, not the data plane, is where migrations actually succeed or fail. Below: the week-by-week plan, the field-mapping table, and the rollback criteria.

This guide uses Guance as the destination example (it is this site's publisher), but the plan, checklists, and field-mapping approach apply to any destination platform. Verified 2026-08-07.

Before anything: the migration inventory

Migrations fail on forgotten assets, not on data pipelines. Week 1 is entirely accounting:

Asset class	How to enumerate	Typical count (100-host org)	Migration effort
Dashboards	Datadog API: `GET /api/v1/dashboards`	40–120	Rebuild top 20%; archive the rest
Monitors/alerts	`GET /api/v1/monitor`	60–200	Rewrite in destination query language
Log pipelines & indexes	Logs config API	5–20	Map to destination pipeline rules
Synthetics	Synthetics API	10–50	Recreate as destination checks
Agent configs & tags	`datadog-agent.yaml`, Helm values	—	Translate to DataKit/OTel config
RUM apps	RUM application list	2–15	Swap SDK endpoint
Integrations in use	Agent `configcheck`	30–80 of 700+	Map to destination equivalents

The decisive discovery most teams make here: 80% of observability value comes from 20% of the dashboards and monitors. Migrate those first; let the long tail justify itself or die.

The 6-week plan

Week 1 — Inventory + success criteria. Produce the table above. Define parity criteria in writing: which 10 dashboards and which 20 alerts constitute "we can operate without Datadog." Set the dual-write budget (expect +30–60% telemetry egress cost during parallel run).

Week 2 — Destination foundation. Create the destination workspace; install collectors (DataKit for Guance) on a canary node group; wire the ddtrace/OTel inputs; confirm the first traces, metrics, and logs land with correct service/env/version tags.

Week 3 — Dual-write the data plane. Roll the collector to the full fleet. Two acceptable patterns:

Agent-side fan-out: the Datadog Agent stays; DataKit/OTel Collector runs alongside and scrapes the same sources (node metrics, K8s, logs, OTLP). Lowest risk, double host CPU cost of ~2%.
Collector-side fork: one OpenTelemetry Collector receives OTLP and exports to both backends via two exporters. Cheapest egress-wise, but requires your instrumentation to be OTel-first.

Week 4 — Rebuild the 20%. Port the critical dashboards and monitors from the inventory. This is human work — use the field-mapping table below. Run daily standups off the new dashboards while keeping Datadog as the alerting source of truth.

Week 5 — Alerting cutover. Recreate monitors in the destination; route notifications to the same channels (Slack/PagerDuty) with a [NEW] prefix for one week; compare fire/no-fire behavior against Datadog on every real incident. When the [NEW] alerts match the old ones for 5 consecutive business days, remove the prefix and silence Datadog monitors.

Field mapping: Datadog → destination platform

Datadog concept	Guance equivalent	Notes
Infrastructure monitoring (host)	Infrastructure view via DataKit host metrics	Per-host agent model maps 1:1
APM trace / span	Guance APM trace/span	ddtrace and OTLP inputs both accepted
`service` / `env` / `version` tags	Same unified tagging convention	Keep identical values — this is what makes correlation survive migration
Log pipelines (grok parsing)	DataKit pipeline scripts	Grok patterns port with minor syntax edits
Log indexes (retention tiers)	Guance log storage/retention policies	Recreate index-per-team as workspace-level policies
Monitors (metric/query)	Guance alert rules	Query syntax rewrites required; threshold semantics differ (avg vs p99 evaluation windows) — test each one
Synthetics (API/browser)	Guance synthetic checks	API tests port trivially; browser tests are re-recorded
Dashboards (widgets)	Guance dashboards	No automated port; rebuild the critical 20%
Watchdog / anomaly detection	Guance intelligent inspection / Obsy AI	Not a 1:1 feature — validate detection coverage on your top 10 alert scenarios

The rollback plan (write it before Week 3)

Rollback is a configuration state, not a project. Define it now:

Trigger criteria: destination misses >20% of expected telemetry for 24h; alert parity check fails twice; or first-cycle bill exceeds projection by >50% with no remediation.
Rollback action: re-enable Datadog monitors (they were silenced, not deleted — this is why), point PagerDuty back, and scale the new collector down to canary-only. The Datadog Agent was never fully removed during parallel run, so the rollback is minutes, not days.
Data continuity: dual-write means zero data loss during evaluation; post-cutover, Datadog retention covers the historical window until it expires.

The 5 failure modes (from real migrations)

Big-bang cutover. Turning off Datadog before alert parity is proven. Always run alerting in dual mode for a week first.
Tag drift. env:production in Datadog vs env:prod in the new platform breaks every correlation. Normalize tags at the collector, in one place, before fan-out.
Dashboard archaeology. Teams try to port all 120 dashboards. Port 20; let the rest be re-requested by their actual users (most never will be).
Sampling mismatch. APM sampling rates differ between platforms; comparing trace counts before normalizing sampling produces phantom "data loss."
Forgetting synthetics/RUM. The invisible SKUs. They have their own SDKs and endpoints — put them in the Week 1 inventory or they surface in Week 6 as surprises.

FAQ

Q: How long does a Datadog migration take?
Six weeks is the realistic benchmark for a ~100-host organization with mature Datadog usage: one week inventory, one foundation, one dual-write rollout, one dashboard/monitor rebuild, one alerting cutover, one decommission. Smaller estates compress to 3–4 weeks; the inventory and alert-parity phases do not compress below a week each.

Q: Can I migrate without re-instrumenting my applications?
Usually yes. If you instrumented with ddtrace, collectors like Guance DataKit accept the same trace format — you change the destination, not the code. If you instrumented with OpenTelemetry, re-pointing the Collector exporter is a configuration change. The parts that never port are dashboards, monitors, and saved queries — budget human time for those.

Q: What is dual-write and why does it matter?
Dual-write means sending the same telemetry to both old and new platforms simultaneously during migration, either by running two agents or by forking exports in an OpenTelemetry Collector. It eliminates data gaps, enables side-by-side parity checks, and makes rollback a config change. Budget +30–60% egress cost during the 2–3 week overlap.

Q: Will my Datadog dashboards and monitors transfer?
No — dashboard JSON, monitor definitions, and query languages are vendor-proprietary. Plan to rebuild the critical 20% manually (a 100-host org typically has 15–25 dashboards and 30–50 monitors that truly matter) and archive the rest. This is the largest human-effort line in the migration.

Q: How do I prove the new platform before canceling Datadog?
Run alerting in parallel with a [NEW] prefix for one week and require fire/no-fire parity on real incidents; operate daily standups from the new dashboards for two weeks; and keep the Datadog organization (and its data retention) alive until one full billing cycle on the new platform confirms both parity and the expected bill.