Replacing a Disappearing Sentry With an End-to-End Datadog Observability Plane

Sentry goes dark next week, and no one can say which services, alerts, or incident clues will disappear with it. Before the switch, the team must prove Datadog can carry an operator from a customer-visible failure to the evidence and owner needed to act.

What is known, and what is not

The current Sentry installation cannot be inspected and is expected to disappear the following week. Datadog is the requested destination, with application APM, AWS telemetry, Cloudflare data, dashboards, and actionable alerts in scope.

That establishes urgency, not equivalence. There is no defensible inventory of current application coverage, alerts, routing rules, retention, integrations, or historical baselines. The complete service topology, traffic volumes, telemetry budget, data classifications, credential owners, and most critical user paths are also unresolved.

Those gaps constrain the plan. They do not justify guessing what existed. Reconstruct operational requirements from source repositories, infrastructure definitions, deployment configuration, runtime inventories, and the people who own user-facing behavior. Record anything that cannot be verified before shutdown as a named coverage risk.

Migration architecture

Users experience requests across layers, so the investigation model must cross them too.

Application traces and structured logs should share trace and span identifiers, with navigation tested in both directions. A safe request ID can connect more of the path when the edge and application both preserve it. It must not contain customer data, credentials, or any other sensitive value.

When no trace ID or safe request ID crosses the edge, Cloudflare correlation remains probabilistic. Narrow candidates with a bounded time window, host, normalized route, status, and timing. Present that result as supporting evidence, never as proof that a specific edge event and trace are the same request.

Telemetry as an interface

Treat telemetry fields as an interface shared by code, deployment automation, resource tags, dashboards, and monitors. One controlled vocabulary covers env, service, and version. Service names identify stable logical applications, not tasks or instances. Versions come from the deployment process so operators can compare symptoms against change history.

Record normalized route templates rather than raw URLs or query strings. Put trace and span identifiers into structured application logs. Map relevant AWS resources to environment, service, and owner. Validate every field against actual investigative questions before making it indexed or searchable.

Cardinality and privacy controls belong at ingestion, not after cost or exposure appears. Exclude email addresses, account identifiers, tokens, request bodies, arbitrary query values, raw paths, and unbounded resource values from tags. Security and privacy owners must review log contents, credentials, retention, access, regional constraints, and redaction before later environments receive data.

Sampling is a loss decision, made explicitly. Lower rates reduce cost but remove ordinary traces permanently: retention cannot recover data that was never captured. Define the expected diagnostic loss for each environment and decide how error and high-latency evidence will be preserved. Avoid claims of complete request history under sampled collection.

What cannot be recovered once Sentry is gone. Any alert threshold, routing rule, or noise baseline that existed only in the Sentry UI is permanently inaccessible. Historical error rates, volume baselines, and aggregated fingerprints disappear with the account. Initial Datadog monitors must carry explicit documentation that their thresholds are provisional, observed from scratch, and not imported from a prior system.

Concrete Datadog implementation

The contract described above maps directly to Datadog configuration. The following slice shows one representative path from tracer setup to alert.

Unified service tagging enforces the env, service, and version vocabulary at the container level:

# Kubernetes deployment env block (representative)
env:
  - name: DD_ENV
    value: "production"
  - name: DD_SERVICE
    value: "checkout-api"
  - name: DD_VERSION
    valueFrom:
      fieldRef:
        fieldPath: metadata.labels['app.kubernetes.io/version']
  - name: DD_LOGS_INJECTION
    value: "true"
  - name: DD_TRACE_SAMPLE_RATE
    value: "0.25"

DD_LOGS_INJECTION: "true" tells the tracer to stamp dd.trace_id and dd.span_id into every structured log line automatically. The version is pinned to a deployment label so it reflects the deployed artifact, not a hardcoded string.

Cloudflare Logpush should deliver the fields the correlation model depends on. A representative field list for the HTTP requests dataset:

["ClientRequestHost","ClientRequestURI","EdgeStartTimestamp",
 "OriginResponseStatus","CacheStatus","EdgeResponseStatus",
 "ClientRequestMethod","RequestHeaders.cf-ray","EdgeColoID",
 "OriginResponseTime"]

cf-ray is Cloudflare's deterministic edge-request identifier. If the application logs it on receipt, edge and trace records share a real join key. Without that header preservation, the join is probabilistic.

AWS integration resource tags should carry the same vocabulary so infrastructure evidence links to services without manual mapping:

# Terraform resource tag block (representative)
tags = {
  Env     = var.env
  Service = var.service
  Owner   = var.team_email
}

The Datadog AWS integration uses these tags to attach resource metrics to the same env and service values the tracer emits.

Monitor query with missing-data behavior. The missing-data setting is load-bearing: a stopped application or broken collector should not appear healthy.

# Datadog monitor query (representative)
sum(last_5m):sum:trace.web.request.errors{env:production,service:checkout-api}.as_count() /
sum:trace.web.request.hits{env:production,service:checkout-api}.as_count() > 0.05
 
# Monitor options (JSON excerpt)
{
  "notify_no_data": true,
  "no_data_timeframe": 10,
  "require_full_window": false,
  "evaluation_delay": 60,
  "message": "Error rate above 5% for checkout-api in production. Runbook: <link>. Owner: @checkout-team"
}

notify_no_data: true with a 10-minute window ensures that a silent collector pages rather than resolves. require_full_window: false prevents the monitor from suppressing alerts when a new deployment is still filling its first evaluation window.

Rollout gates

The central test at every gate is the same: can an operator move from a visible symptom to evidence and a named owner? Each gate below contributes a distinct mechanism or failure mode rather than repeating that test.

Dashboards should answer a short chain of questions: Is a user-visible symptom changing? Which environment, service, route, or version is affected? Does evidence point to the edge, infrastructure, a dependency, or an application span? Did a deployment coincide with it? Which owner acts next?

Panels need a declared source and a link to narrower evidence. Dashboards need a purpose, owner, review date, and retirement rule. Historical thresholds cannot be imported from the inaccessible installation, so initial monitors require conservative settings, observation, and documented tuning rather than invented baselines.

Alerts begin with user-visible symptoms, capacity exhaustion, dependency failures, and missing telemetry. Each alert defines its scope, evaluation window, minimum traffic threshold, missing-data behavior, owner, destination, and first investigative action. Minimum traffic prevents unstable rates from paging on tiny samples. Missing-data alerts distinguish a quiet system from a broken collector, absent integration, or stopped application.

Acceptance probe: trace a known test request

This is a proposed verification scenario, not a completed event.

Send a controlled request through a discovered, approved user-visible path in development. Use a safe test marker or request identifier only if policy and the actual stack permit it. The operator must then navigate the following steps, resolving each before moving to the next:

Find the corresponding edge evidence and determine whether the request reached the origin. Identify the relevant AWS resource or dependency evidence without relying on an invented resource name. Reach the application trace, its spans, and correlated structured logs, or document that the edge-to-trace step is only a bounded probabilistic join. Confirm consistent environment, service, version, normalized route, and status fields across layers. Verify that no restricted or high-cardinality data was captured. Follow the dashboard or alert context to a named owner and a specific first action.

The exit criterion is successful navigation through every deterministic link, honest labeling of every probabilistic link, acceptable data handling, and an accountable destination. Any step that depends on tribal knowledge or an unsupported assertion stops promotion.

FAQ

Should the old setup be reproduced?

No equivalence claim is supportable without access. Recover requirements from available technical evidence, critical user paths, and owners, then document residual gaps.

What comes first?

Start with the inventory and telemetry contract. Validate application traces and structured logs in development before expanding cloud and edge collection.

When is the migration complete?

Not when data appears. Completion requires accepted coverage, tested investigation paths and alerts, named ownership, controlled cost and privacy, and documented limitations in every intended environment.

The operational cost of maintaining the telemetry contract is real and ongoing. Tags drift. Services get renamed without updating DD_SERVICE. New teams skip the privacy review. Designate a named reviewer for the contract, schedule quarterly audits, and treat tag drift the same way you treat a broken test: stop promotion until it is fixed.