Observability and error tracking migration
Sentry → Datadog
Move applications, services, and entity identity, metrics and metric types, logs, parsing, and pipelines, traces, spans, and sampling, errors, issues, releases, and source maps, dashboards, queries, and variables, monitors, alert conditions, and notifications, slos, incidents, and burn-rate policy from Sentry to Datadog with a reversible cutover, explicit exception ledger, and evidence-backed verification.
Typical timeline15–45 business days70–180 hours active work
This route needs review.Use it as a planning baseline, then verify the dated sources and test with representative data before production.
Before you migrate
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Current platform
Sentry
Reasons to stay
- Developer-focused error tracking, traces, releases, profiling, and source-code context accelerate debugging
- Centralized telemetry, dashboards, alerts, and incident signals shorten diagnosis time
Reasons to leave
- Issue grouping, event quotas, release setup, and historical error state are vendor-specific
- Historical telemetry, query languages, alert behavior, and instrumentation do not move cleanly
New platform
Datadog
What gets better
- Broad infrastructure, APM, logs, security, dashboards, and integrations offer a unified operational view
- Centralized telemetry, dashboards, alerts, and incident signals shorten diagnosis time
What gets worse
- Usage-based pricing, product sprawl, and proprietary queries can become difficult to govern
- Historical telemetry, query languages, alert behavior, and instrumentation do not move cleanly
Best of the move
Datadog: Broad infrastructure, APM, logs, security, dashboards, and integrations offer a unified operational view. This removes a major source-side concern: Issue grouping, event quotas, release setup, and historical error state are vendor-specific.
Worst of the move
What you lose: Developer-focused error tracking, traces, releases, profiling, and source-code context accelerate debugging. What you inherit: Usage-based pricing, product sprawl, and proprietary queries can become difficult to govern.
Jump to a section
Know the shape of the move.
Clean0
Partial6
Manual3
Lost1
SourceSentry9 mapped fields
Automatic0
Transform6
Manual2
Unsupported1
DestinationDatadog8 supported paths
This timeline assumes
- Up to 2,000 services, 1,000 dashboards, 5,000 alerts, and 100 TB of retained telemetry
- Administrators control both Sentry and Datadog, including billing, identity, APIs, integrations, and export permissions.
- Sentry remains intact and recoverable until Datadog completes one representative operating cycle.
- A production-shaped pilot includes every object type, access class, edge case, and failure path.
- The migration team preserves stable source identifiers and records durable evidence for every blocking check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Applications, services, and entity identity | partial | critical | Service names, environments, releases, hosts, containers, and ownership tags must be normalized. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Map applications, services, and entity identity explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Metrics and metric types | partial | critical | Counters, gauges, distributions, rollups, cardinality, units, and retention behave differently. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Map metrics and metric types explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Logs, parsing, and pipelines | partial | critical | Collection agents, parsing rules, enrichment, redaction, archives, and indexes require redesign. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Map logs, parsing, and pipelines explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Traces, spans, and sampling | partial | critical | Instrumentation, propagation, sampling, service maps, and trace retention are not portable history. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Map traces, spans, and sampling explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Errors, issues, releases, and source maps | partial | critical | Grouping algorithms, fingerprints, release health, source maps, and issue state differ. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Map errors, issues, releases, and source maps explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Dashboards, queries, and variables | partial | high | Dashboard JSON can move only after query languages, widget types, and entity references are translated. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Map dashboards, queries, and variables explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Monitors, alert conditions, and notifications | manual | critical | Thresholds, evaluation windows, anomaly models, muting, routing, and escalation require reconstruction. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Inventory and rebuild monitors, alert conditions, and notifications, then test normal, edge, failure, and rollback behavior. |
| SLOs, incidents, and burn-rate policy | manual | critical | SLI definitions, error budgets, incident objects, and burn alerts use different semantics. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Inventory and rebuild slos, incidents, and burn-rate policy, then test normal, edge, failure, and rollback behavior. |
| Historical telemetry and baselines | lost | high | Large retained telemetry datasets rarely transfer into native destination storage. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Archive historical telemetry and baselines as dated source evidence and define the new destination baseline. |
| Agents, API keys, integrations, and cost controls | manual | critical | Collectors, secrets, cloud integrations, quotas, indexes, and retention policies must switch deliberately. A successful bulk job therefore does not prove semantic parity between Sentry and Datadog. | Inventory and rebuild agents, api keys, integrations, and cost controls, then test normal, edge, failure, and rollback behavior. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Sentry: Applications, services, and entity identity | Datadog: approved applications, services, and entity identity representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for applications, services, and entity identity. |
| Sentry: Metrics and metric types | Datadog: approved metrics and metric types representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for metrics and metric types. |
| Sentry: Logs, parsing, and pipelines | Datadog: approved logs, parsing, and pipelines representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for logs, parsing, and pipelines. |
| Sentry: Traces, spans, and sampling | Datadog: approved traces, spans, and sampling representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for traces, spans, and sampling. |
| Sentry: Errors, issues, releases, and source maps | Datadog: approved errors, issues, releases, and source maps representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for errors, issues, releases, and source maps. |
| Sentry: Dashboards, queries, and variables | Datadog: approved dashboards, queries, and variables representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for dashboards, queries, and variables. |
| Sentry: Monitors, alert conditions, and notifications | Datadog: approved monitors, alert conditions, and notifications representation | manual | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for monitors, alert conditions, and notifications. |
| Sentry: SLOs, incidents, and burn-rate policy | Datadog: approved slos, incidents, and burn-rate policy representation | manual | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for slos, incidents, and burn-rate policy. |
| Sentry: Historical telemetry and baselines | No destination | unsupported | Retain immutable source evidence; do not manufacture destination-native history. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Sentry data, configuration, access, and operating evidence before any destination write.
- Export every available Sentry object and binary in scope, including applications, services, and entity identity, metrics and metric types, logs, parsing, and pipelines, traces, spans, and sampling.
- Capture configuration and runtime dependencies for errors, issues, releases, and source maps, dashboards, queries, and variables, monitors, alert conditions, and notifications, slos, incidents, and burn-rate policy.
- Record counts, sizes, owners, timestamps, access classes, financial totals where applicable, and known exceptions.
- Hash immutable exports, record tool versions and commands, and transform working copies only.
Proof to capture: A signed manifest accounts for every scoped record class, configuration object, binary, count, total, exception, and hash.
Identity, schema, and disposition registry
Preserve stable identity and make every mapping or exclusion reviewable.
- Inventory source types, identifiers, owners, states, and access.
- Define one approved destination representation or explicit archive decision.
- Reject unmapped critical items and produce an exception ledger.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Dependency-ordered migration package
Load prerequisite identities and configuration before dependent records and runtime actions.
- Normalize encoding, timestamps, identifiers, nulls, and destination limits.
- Run a representative pilot and retain request, response, and rejection evidence.
- Reconcile the final delta before enabling destination production writers.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
Import
A completed migration hides missing or altered applications, services, and entity identity
criticalpossible likelihood
Headline counts look plausible while semantic, access, or relationship checks fail.
- Consequence
- The destination becomes authoritative with incomplete or misleading business data.
- Mitigation
- Reconcile by type, state, owner, access class, and representative record rather than total count alone.
Stop if: Any critical item lacks a verified destination, approved transformation, explicit exclusion, or recoverable archive.
Cutover
Sentry and Datadog both perform production actions
criticalpossible likelihood
Users, schedules, webhooks, integrations, or traffic continue changing both systems.
- Consequence
- State diverges or customers receive duplicate, contradictory, or unsafe actions.
- Mitigation
- Freeze source writers and transfer one production owner at a time with an approved rollback.
Stop if: An unapproved source writer or destination duplicate action appears after the freeze.
Verification
Destination access or security is broader than approved
criticalpossible likelihood
A representative restricted user can read, change, export, or trigger an unauthorized item.
- Consequence
- Confidential, regulated, financial, or security-sensitive data is exposed or changed.
- Mitigation
- Apply least privilege before bulk loading and test every access class using ordinary identities.
Stop if: Any unauthorized read, write, export, administrative action, or secret access succeeds.
Do the work in this order.
Estimate forUp to 2,000 services, 1,000 dashboards, 5,000 alerts, and 100 TB of retained telemetry
Total elapsed15–45 business days
Active work70–180 hours
BufferAdd time for large Sentry exports, destination rate limits, unsupported features, identity exceptions, regulated data, or a strict downtime objective.
01
Days 1–4Inventory and decisions2–4 days
02
Days 3–8Backup and reconcile2–5 days
03
Days 6–20Map, transform, and pilot5–12 days
04
Days 18–35Bulk load, final delta, and switch2–8 days
05
Days 25–45Observe and close7–14 days
- Days 1–4 · inventory
Inventory and decisions
8–16 hours active2–4 days elapsedOwner, legal, security, and finance review waiting- Inventory Sentry data, configuration, identities, integrations, limits, and billing.
- Approve scope, owners, mappings, exclusions, acceptance thresholds, and rollback authority.
Depends on: Sentry and Datadog administrator access
Stop / go checkpointExport?
Go when: Every critical item and production action has an owner and disposition.
Stop when: Authority, retention, billing, access, or system ownership is unclear.
- Days 3–8 · backup
Backup and reconcile
8–20 hours active2–5 days elapsedProvider export processing waiting- Create immutable data, configuration, binary, and audit exports.
- Reconcile source counts, totals, sizes, access classes, and hashes.
Depends on: Approved inventory and retention location
Stop / go checkpointTransform?
Go when: The signed source manifest and exports agree.
Stop when: Any critical dataset, binary, configuration, or recovery path is absent.
- Days 6–20 · pilot
Map, transform, and pilot
25–70 hours active5–12 days elapsedDestination processing and owner review waiting- Configure Datadog and transform a production-shaped pilot.
- Test normal records, every feature class, edge cases, permissions, failures, and rollback.
Depends on: Verified source backup and approved mapping registry
Stop / go checkpointScale?
Go when: Every pilot mapping and blocking verification check passes.
Stop when: Any critical invariant, access boundary, or production action lacks a safe destination.
- Days 18–35 · cutover
Bulk load, final delta, and switch
20–55 hours active2–8 days elapsedImports, propagation, indexing, or synchronization waiting- Freeze production writes and automated actions in Sentry.
- Apply and reconcile the final delta, switch ownership to Datadog, and run all blocking checks.
Depends on: Passed pilot, stakeholder go decision, and rehearsed rollback
Stop / go checkpointOpen production?
Go when: Datadog is the sole production owner and every critical exception is resolved.
Stop when: A source writer remains active, a blocking check fails, or rollback is unavailable.
- Days 25–45 · observe
Observe and close
9–19 hours active7–14 days elapsedRepresentative operating-cycle evidence waiting- Monitor correctness, access, failures, latency, delivery, cost, and user outcomes.
- Sign the verification report and close rollback only after stable evidence.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the approved observation period.
Stop when: Data, access, delivery, routing, cost, or business results regress.
Cut over with a way back.
Cutover
Make Datadog the only production system without losing the final Sentry delta.
- Freeze user, integration, schedule, and API writes in Sentry.
- Capture and reconcile the final source delta against the last verified checkpoint.
- Apply the approved delta and configuration changes to Datadog.
- Switch traffic, domains, integrations, credentials, automation, and user entry points in dependency order.
- Run every blocking verification check and keep the source intact.
Proof to capture: Datadog alone owns production, totals reconcile, exceptions are signed, and every blocking check has durable evidence.
Rollback
Return production ownership to Sentry without losing destination-era changes.
- Stop new user, integration, schedule, and API writes in Datadog.
- Restore prior Sentry traffic, domains, credentials, automation, and integration ownership.
- Export and classify the Datadog post-cutover delta.
- Apply safe destination-era changes back to Sentry without duplicating actions.
- Run the same blocking checks against the restored source.
Proof to capture: Sentry again owns production with current data and no duplicate destination action.
Rollback immediately when
- Unexplained critical count, value, relationship, or checksum variance
- Missing, corrupted, or exposed critical data
- Duplicate production action or unresolved split-brain state
- Failed access, security, delivery, routing, performance, or integration check
- A critical feature has no safe destination replacement or rollback path
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Applications, services, and entity identity reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for applications, services, and entity identity. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Applications, services, and entity identity ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-02Blocking | Metrics and metric types reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for metrics and metric types. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Metrics and metric types ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-03Blocking | Logs, parsing, and pipelines reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for logs, parsing, and pipelines. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Logs, parsing, and pipelines ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-04Blocking | Traces, spans, and sampling reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for traces, spans, and sampling. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Traces, spans, and sampling ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-05Blocking | Errors, issues, releases, and source maps reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for errors, issues, releases, and source maps. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Errors, issues, releases, and source maps ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-06 | Dashboards, queries, and variables reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for dashboards, queries, and variables. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Dashboards, queries, and variables ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-07Blocking | Monitors, alert conditions, and notifications reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for monitors, alert conditions, and notifications. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Monitors, alert conditions, and notifications ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-08Blocking | SLOs, incidents, and burn-rate policy reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for slos, incidents, and burn-rate policy. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | SLOs, incidents, and burn-rate policy ledger with counts, exceptions, sample IDs, and owner sign-off. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check and exception.
- Create final Sentry exports and archive verification, access, financial, and rollback evidence.
- Revoke temporary credentials, API keys, webhooks, elevated roles, and migration network access.
- Remove obsolete jobs, embeds, domains, integrations, collectors, routes, and DNS records.
- Keep the source intact and read-only through the approved legal and operational retention window.
- Cancel paid plans only after billing, legal, security, evidence, and recovery review.
- Schedule the next Datadog backup, restore test, access review, and migration-playbook review.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- Sentry: official portability and migration documentationAccessed 2026-07-20
- Datadog: official portability and migration documentationAccessed 2026-07-20