Skip to main content
This article outlines a practical, phased approach to migrating observability from one platform to another (for example, to Datadog). We recommend a staged migration that reduces risk, allows incremental validation, and captures learnings that scale across teams. Quick comparison of migration strategies:
StrategyWhen to useProsCons
Phased approachLarge environments, multiple teams, complex integrationsSafer rollout, smaller blast radius, iterative validation, reusable artifactsLonger overall timeline
Big-bang approachSmall, simple environments or when cutover window is fixedFaster full migrationHigher risk, harder to diagnose missed telemetry and config issues
The image compares two approaches: the "Phased Approach," which is safer and slower with features moved one at a time, and the "Big-Bang Approach," which involves a full, fast switch with higher risk and less planning.
For most organizations, a phased migration is the recommended pattern. It enables feedback-driven improvements, reduces risk, and produces repeatable artifacts (charts, config, documentation) that accelerate subsequent teams.
Most migration tasks (agent rollout, integrations, telemetry validation) are similar regardless of approach; the difference is how and when you cut over traffic and retire the old platform. Below we walk through a validated sequence you can adapt to either strategy.

​
Initial access and prerequisites

Before installing agents or flipping integrations, gather access and artifacts so engineering teams aren’t blocked.
  1. Obtain platform and identity access
    • Identity and access management (IAM) and identity governance systems (for example, Microsoft Entra ID (Azure AD) or AWS IAM). IGA vendors may include tools such as SailPoint.
    • Create or request service accounts, roles, and permissions required to install agents and configure platform integrations.
  2. Collect installer artifacts and libraries
    • Helm charts or Kubernetes manifests for cluster deployments.
    • Agent packages for VMs, containers, or serverless runtimes.
    • Language-specific instrumentation libraries and SDKs for application code.
  3. Prepare environment-specific credentials
    • Cloud account access, API keys, and any secrets needed to onboard telemetry (metrics, traces, logs, and profiling).
Request IAM roles and service account permissions early. Missing privileges are a common cause of migration delays—apply least privilege principles and document required scopes for onboarding.
Make these requests early so platform engineers and application teams can proceed without delays.
The image shows an approach diagram, featuring an engineer accessing IAM, platform packages, and environment, each with specific examples like roles, Helm charts, and cloud accounts.

​
Setting up the environment

Start in a development environment and iterate until telemetry is correct. For Datadog, typical tasks include:
  • Deploy the Datadog Agent:
    • Kubernetes: install via Helm chart or DaemonSet.
    • Containers: run the agent as a sidecar or daemon container.
    • VMs: install with package installers (apt, yum) or agent images.
  • Enable and configure integrations:
    • Metrics, logs, traces/APM, and continuous profiling.
    • Configure Prometheus-style scrapes for services exposing /metrics.
  • Tune collection concerns:
    • Log filters and processors to reduce noise and cost.
    • Metric collection intervals and custom tags for better grouping.
    • Trace sampling rules to control ingestion volume.
Use development to validate collection, refine configuration, and confirm ingestion into the new platform before promoting changes to staging and production.
The image illustrates an approach where telemetry data flows from development environments like Kubernetes, Virtual Machines, and Serverless into Datadog, which includes logs, metrics, traces, and profiles, with validation by end users.

​
Validation and feedback loop

A structured validation loop ensures issues are caught early and fixes are distributed as shared artifacts:
  • Allow time for telemetry to arrive and stabilize in the platform (metrics graphs, log indices, traces).
  • Run user acceptance tests and have engineers validate dashboards, alerts, and traces.
  • Capture and prioritize feedback (missing spans, unexpected metrics, noisy logs).
Feedback workflow example:
  • Engineers report issues (e.g., missing spans, incorrect metrics, noisy logs).
  • Platform team investigates, implements configuration fixes, adds filters, and updates documentation.
  • Platform team publishes the fixes and reusable templates (Helm values, config snippets, alert rules) for downstream teams.
The image depicts a flowchart showing communication between engineers and other teams with a platform team. Engineers encounter issues like errors and high CPU usage, while other teams focus on enhancing communication, fixing bugs, and improving documentation.
That’s it for this article. Thanks for reading and good luck with your observability migration.

Watch Video