Acme

Migrating from proprietary agents to OpenTelemetry

A phased migration plan that keeps your dashboards working while you switch to vendor-neutral instrumentation.

EV
Elena Vasquez
Senior Platform Engineer

Vendor-specific agents made sense when observability backends were islands. Today, OpenTelemetry is the CNCF standard for traces, metrics, and logs — and every major platform including Acme accepts OTLP natively. Migrating does not require a big-bang rewrite; it requires a phased plan that keeps production dashboards green while you cut over service by service.

Phase zero is inventory. List every language runtime, every proprietary agent, and every auto-instrumentation hook currently running. Map which services emit metrics only versus full traces. Acme's integration scanner connects to Kubernetes and reports which pods still run legacy agents — most teams discover 20–30% more agents than they expected.

Phase one deploys the OpenTelemetry Collector as a DaemonSet or sidecar without changing application code. Configure dual export: send identical telemetry to your existing backend and to Acme ingest endpoints. Compare dashboards for two weeks. Discrepancies usually reveal metric naming differences, not data loss.

Phase two replaces auto-instrumentation. Java, Node.js, Python, and Go all have mature OTel SDKs with drop-in agents. Start with stateless API services — they restart easily and have clear golden signals. Keep proprietary agents running in parallel until Acme dashboards match within agreed tolerances.

OpenTelemetry architecture diagram with traces metrics and logs flowing through the collector
The Collector becomes your migration control plane — dual-export to legacy and Acme during transition.

Custom spans require more care. If your legacy agent injected custom business metrics, recreate them with OTel meter API rather than assuming automatic parity. Document a naming convention early: `service.namespace.metric_unit` prevents the cardinality problems that migrations sometimes introduce.

Logs are often the last signal migrated because teams fear losing parsing pipelines. Acme accepts OTLP logs with structured attributes preserved. Map Grok patterns to OTel resource attributes where possible — hostname, pod name, and deployment version should be resource-level, not duplicated in every log line.

Trace context propagation is the hidden migration risk. Ensure W3C traceparent headers flow through ingress controllers, service meshes, and async queues. A broken propagation chain makes distributed traces look like unrelated spans — worse than no traces at all. Run synthetic transactions through your critical paths and verify end-to-end trace IDs in Acme.

Train teams on Collector configuration as infrastructure-as-code. Helm values for the Collector belong in the same repo as application manifests. Version pin the Collector image; silent upgrades have broken export pipelines in production more than once across the industry.

Set a hard sunset date for proprietary agents per cluster. Open-ended dual-run periods become permanent technical debt. Vertex SaaS migrated 140 services over four months with a weekly quota of five services — aggressive enough to finish, conservative enough to avoid heroics.

When migration completes, you gain portability. Switching observability backends no longer requires re-instrumenting applications — only re-pointing the Collector. That negotiating leverage alone has saved Acme customers an average of 37% on tool consolidation. Start your migration this sprint with our OpenTelemetry integration guide and the Academy video walkthrough.