How to Migrate from Datadog to OpenTelemetry-Native Observability

OpenTelemetry adoption statistics (2024-2026)

• 48.5% of enterprises currently use OpenTelemetry (Enterprise Management Associates, March 2025)
• 25% planning to implement, 25% evaluating
• Second most active CNCF project (behind Kubernetes)
• 45% YoY increase in GitHub commits (2024)
• 10,000+ individual contributors from 1,200+ companies

The industry is standardizing on OpenTelemetry. Migrating now positions your team for long-term flexibility.

SDK stability status (early 2026)

Feature mapping: Datadog to OpenTelemetry

Migration timeline estimates

Case study: leboncoin migrated 900+ microservices in 4 phases and achieved 30% reduction in Datadog costs.

Phase 1: Dual-running configuration

The safest migration approach is running both platforms simultaneously. The OTel Collector can export to multiple backends:

exporters:
  # Continue sending to Datadog during migration
  datadog:
    api:
      key: ${DD_API_KEY}
  # New OpenTelemetry-native backend
  otlp/new-backend:
    endpoint: "https://your-backend:4317"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [datadog, otlp/new-backend]  # Both!
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [datadog, otlp/new-backend]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [datadog, otlp/new-backend]

This configuration sends identical telemetry to both platforms, allowing side-by-side comparison before cutting over.

Phase 2: Instrument services with OTel SDKs

Replace Datadog agents with OpenTelemetry instrumentation. For most languages, this involves:

Java (auto-instrumentation)

# Download the agent
curl -L https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar -o opentelemetry-javaagent.jar

# Run with agent
java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.service.name=my-service \
  -Dotel.exporter.otlp.endpoint=http://collector:4317 \
  -jar my-application.jar

Python

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install

# Run with auto-instrumentation
opentelemetry-instrument \
  --service_name my-service \
  --exporter_otlp_endpoint http://collector:4317 \
  python my_app.py

Node.js

npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node

# In your application entry point
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');

const sdk = new NodeSDK({
  serviceName: 'my-service',
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Phase 3: Validate and compare

During dual-running, validate that:

• Trace counts match between platforms
• Metric values are consistent
• Log volume is equivalent
• Alerts fire appropriately on both systems

Run dual for at least 2-4 weeks to cover normal traffic patterns and potential edge cases.

Phase 4: Cut over and decommission

Once validated:

1. Update runbooks and documentation
2. Train team on new platform
3. Remove Datadog exporter from Collector config
4. Decommission Datadog agents
5. Cancel Datadog contract (check renewal terms)

Frequently asked questions

Why migrate to Sampleless?

Sampleless is OpenTelemetry-native from the ground up. Your OTel instrumentation sends data directly to our collectors with zero translation layer.

Because we use open standards, migrating away from Sampleless is equally straightforward. Your instrumentation works with any OTel-compatible backend. No lock-in.