Adopt OpenTelemetry as an instrumentation and transport boundary before deciding whether to replace Datadog. Evaluate Grafana Cloud as a managed destination when it fits the team’s investigation workflow, and retain Datadog when its OpenTelemetry path meets the portability requirement. A backend change is not the only way to reduce dependence on proprietary instrumentation.
Procurement should define portability concretely. Can the application emit telemetry without a vendor-specific SDK? Can collectors route it elsewhere? Can the team recreate the alerts and investigations that matter? Those are related but different requirements.
Separate collection from investigation
Datadog documents several OpenTelemetry ingestion paths, including Collector-based and other OTLP options. That is a reason to test the current backend before planning a wholesale migration. The exact path matters because enrichment and supported behavior can differ.
Grafana Cloud supports OTLP telemetry ingestion. It is a credible managed alternative when the team wants to evaluate another backend without changing every application emitter. A shared transport does not mean dashboards, queries, derived metrics, and alert definitions are interchangeable.
The OpenTelemetry gateway pattern provides a shared collection and export tier. Use that boundary where centralized routing and processing are useful. Keep the collector configuration under application-platform ownership so destination changes remain inspectable.
Define a portability acceptance test
Choose one service with traces, metrics, and logs that support a real incident investigation. Record the attributes needed to connect those signals: service identity, environment, release, and relevant resource context. Then send a controlled dataset through the proposed pipeline to both destinations.
Compare the answers to practical questions. Can an engineer locate a failing request, see the release involved, identify a slow dependency, and find the related logs? Check whether the metric interpretation and sampling assumptions remain consistent. Successful ingestion alone is insufficient.
Inventory vendor-specific instrumentation and features currently used. Some may be valuable enough to retain deliberately. Label those dependencies so the procurement requirement describes the remaining exit work honestly rather than claiming complete portability.
Compare operating and commercial scope
Managed backend adoption still leaves decisions about collection, redaction, cardinality, sampling, and data ownership. Estimate those responsibilities from the pilot. Obtain quotes using the same retained volume and required features, rather than assuming an open protocol implies a lower bill.
Include migration of alerts and saved investigations. A dashboard export is not proof that another product interprets the query identically. Keep the old alerting path authoritative until the replacement has been tested without creating duplicate pages.
Choose Grafana Cloud when the pilot proves its investigation workflow and commercial offer fit. Keep Datadog when its OpenTelemetry integration satisfies the collection boundary and the existing workflow remains valuable. Begin with a written portability contract and one service emitting a representative dataset; that makes the purchasing decision evidence-based without requiring a premature backend exit.
Research date: 2026-09-05.
Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.
Read our editorial approach ↗