Planning observability consolidation at enterprise scale: a practical guide

Last week I attended DASH, Datadog's annual conference. Beyond the product announcements, I was impressed by how many large enterprises are modernizing their observability stack on Datadog.

Experian talked about migrating more than 100 dashboards, converting over 3,000 log-based alerts, and cutting logging costs.

AdventHealth described consolidating observability and security across 55 hospitals and more than 100,000 endpoints, then completing a critical security migration in four weeks.

Both stories highlighted something important: observability consolidation has become a strategic initiative for enterprise platform teams.

Watching those presentations, I kept wondering: How do organizations confidently plan migrations at that scale?

Before anyone upgrades SDKs, rewrites instrumentation, or opens a pull request, platform teams need an accurate picture of what's deployed across thousands of repositories. In reality, most don't have that visibility. That's why migrations that look straightforward on paper often take months to complete.

Once an organization has aligned on its observability strategy, the engineering work begins inside the codebase.

Across hundreds of repositories, platform teams need answers to questions like:

• Which services still use legacy logging libraries?
• Where has OpenTelemetry already been adopted?
• Which applications still depend on prom-client?
• Which repositories still emit unstructured logs?
• Which services already include observability SDKs?
• Which configuration files define logging, tracing, metrics, or Datadog settings?

These aren't reporting questions. They're engineering questions.

You can answer some of them with grep or GitHub search. But once you're looking for API usage, instrumentation patterns, or deprecated libraries, text search stops being enough. You need something that understands code.

That's why we built a set of read-only mining codemods.

Unlike a traditional codemod, they don't rewrite anything. They scan repositories and produce an inventory of what exists today.

For observability migrations, that means answering questions like:

We packaged all six as observability-consolidation-bundle on the Codemod Registry, so you can run the full inventory in one workflow.

Run the bundle across your repositories and aggregate the results in Codemod Insights. Suddenly the migration has a shape.

You can see how much work exists, where it lives, and which teams own it.

To demonstrate the approach, we ran the miners against Backstage, Spotify's open-source developer portal. It's a large TypeScript monorepo with a realistic mix of OpenTelemetry, Prometheus, logging, and Datadog integrations.

The first view gives engineering leadership a high level picture of the migration: estimated effort, cost, timeline, and team impact. Instead of guessing, leaders can track progress and plan capacity with confidence.

The second view helps platform teams execute the migration. It highlights the remaining migration surfaces, hotspots, and directories that require attention, making it easy to prioritize the next set of changes.

At this point, nothing has been migrated.

But the unknowns are gone.

Leadership can estimate the effort. Platform teams know where to start. Individual teams know what they own.

The teams speaking at DASH showed what's possible when observability modernization is executed well at enterprise scale. Those transformations don't start with migration scripts. They start with understanding the blast radius.

That's exactly why we are building Codemod.