OpenTelemetry migration services

What an OpenTelemetry migration involves

OpenTelemetry is a framework and toolkit for generating, exporting and collecting telemetry such as traces, metrics and logs. It was formed as a Cloud Native Computing Foundation project by merging OpenTracing and OpenCensus, and it is not an observability backend. That distinction shapes the work: a migration usually changes how telemetry is collected and routed, while storage and dashboards may stay where they are or change on their own schedule. Teams that treat the project as a backend swap tend to underestimate the instrumentation and routing effort.

Most migrations start from one of four triggers: a vendor license change that makes the current agent costly or restrictive, an agent reaching end of life, a need to send the same telemetry to several vendors, or a planned move to a different backend. Each trigger affects the order of work. A license change may force a fast cutover, while a multi-vendor need usually justifies building the Collector routing first and migrating services afterward. Confirm which trigger applies, because it sets the deadline and the number of signals you must carry through the change.

Most teams split the work between their own platform staff and an outside partner. Platform staff usually own the backend, access to the environment, dashboards and alert rules, since they know the existing telemetry and its consumers. A partner is often brought in for the instrumentation changes, attribute mapping and the cutover plan, where repeated work across services benefits from a shared method. Agree on who owns each signal, each service and each rollback step in writing before the first service moves.

Ask any partner or internal lead to produce an inventory of services, languages, existing agents and dashboards that depend on current telemetry names. That inventory drives the scope and any quote. Confirm which OpenTelemetry Collector release and which SDK versions your languages will use, and check the status of each component you plan to rely on, since stability differs across components. These checks determine whether the migration can run side by side with the old agents or needs a hard switch for each service.

What the migration work includes

A migration moves telemetry from proprietary agents, OpenTracing or OpenCensus instrumentation to OpenTelemetry in ordered stages, so each stage can be checked before the next starts. Each package below ends with a named deliverable you keep.

Telemetry inventory

We list every agent, SDK, library and exporter currently emitting traces, metrics and logs, with the services and hosts each one covers. The inventory records which signals each source produces and which backend receives it. Ask for this list to include agents that bundle a second collector, since those often hide duplicate data paths.

Attribute and name mapping

Existing span names, metric names and attribute keys are mapped to OpenTelemetry semantic conventions, and gaps are marked where no convention applies. The mapping shows which dashboards, alerts and queries depend on each old name, so renames are planned rather than discovered later. The deliverable is a mapping document under version control with an owner for each open item.

Collector agent and gateway pipelines

We design which Collectors run as agents beside workloads and which run as gateways that receive from many sources. Receivers, processors and exporters are written as configuration files kept in version control, with the components limited to those the design needs. Confirm the component stability levels listed in each Collector component's README before accepting the pipeline design.

Dual-running period

During dual running, old agents and OpenTelemetry instrumentation send data at the same time so results can be compared service by service. The team checks span counts, metric values, latency and missing attributes against the baseline. Duration depends on how many services change and how many signals each one emits, so ask for the exit criteria in writing before the period starts.

Backend switch

Traffic is moved from the old backend to the target backend one group of services at a time, with a documented rollback path for each group. Retention, query access and alert routing are confirmed on the new backend before any cutover. Backend storage and ingest are often the largest recurring cost, so the switch plan should state expected telemetry volume per group.

Dashboard and alert rebuilding

Dashboards, saved queries and alert rules are rebuilt against the mapped names and attributes, then compared with the originals during dual running. Alerts are tested with known failure conditions so a silent alert is caught before cutover. The deliverable is a rebuilt dashboard set and alert catalog with each item linked to its owning team.

Retirement of old agents

Old agents, exporters and their configuration are removed from hosts, images and deployment templates once the backend switch is accepted. Removal covers credentials, network rules and licenses tied to the old vendor, so none remain active. The retirement record lists each removed component, the date it was removed and the owner who signed off.

What drives cost and duration

The factors that most change how much work an OpenTelemetry migration takes, why each one matters, and how to keep it contained.

Driver	Why it raises effort	How to keep it down
Number of services and languages	Each service needs its own instrumentation change, test and rollout, and each language has its own SDK, agent and configuration pattern.	Start with a narrowed first wave of services that share a language or framework, then add languages in later waves once the pattern is proven.
Starting point: proprietary agent versus OpenTracing or OpenCensus	Proprietary agents often bundle auto-instrumentation and vendor settings that must be replaced, while OpenTracing or OpenCensus code needs API calls rewritten to OpenTelemetry equivalents. OpenTracing and OpenCensus projects were merged into OpenTelemetry, so the bridge work differs by source.	Inventory each service by its current library and agent before planning. Group services by starting point so each group gets one migration pattern.
Depth of custom attributes and vendor-specific features	Custom span attributes, vendor-only sampling rules, proprietary context propagation and bespoke dashboards each need a decision on whether to keep, map or drop them.	Agree a fixed attribute map before instrumenting anything. Keep vendor-only features out of scope unless a business owner signs off on them.
Dashboards and alert rules that depend on old names	Renamed metrics, spans and attributes break dashboards and alert rules, and each broken alert is a possible blind spot during cutover.	Retire unused dashboards and alerts before migration. Compare old and new names side by side and update alert rules in the same change as the service.
Telemetry volume during dual running	Running the old agent and OpenTelemetry together doubles emitted telemetry for the overlap period, which increases ingest cost and Collector load.	Limit dual running to the first wave, sample the duplicate stream where the backend allows it, and set a fixed date to stop the old pipeline.
Number of backends and destinations	Each backend needs its own exporter configuration, credentials, retention settings and validation of data arriving intact. Moving to a new backend adds a second migration on top of the instrumentation work.	Decide early whether the backend changes in the same project. If it does, plan the Collector gateway first and move backends in a separate, later step.
Environments and change windows	Each environment (development, test, staging, production) needs its own rollout and verification, and production changes may only be allowed in fixed windows.	Use the same Collector configuration across environments with only endpoints and credentials changing. Book change windows for the whole wave at once.
Compliance and data-handling requirements for telemetry content	Traces and logs can contain personal data, credentials or regulated identifiers. Redaction rules, data residency, retention and access reviews add design and testing steps.	Classify telemetry fields before the attribute map is fixed. Use the Collector redaction processor for sensitive attributes and record the rules as evidence. Confirm retention and residency requirements with your compliance owner.

Migration phases and outputs

The sequence moves services from proprietary agents, OpenTracing or OpenCensus to OpenTelemetry in controlled waves, with a written output at each phase.

Inventory services and existing telemetry
Your team and DeployOpen list every service, its current agent or OpenTracing or OpenCensus library, the signals it emits, and the dashboards, alerts and backends that depend on them. Attribute names that differ from OpenTelemetry semantic conventions are mapped now. The phase closes when the inventory is signed off and each service has an owner and a migration approach.
Design SDK, Collector and backend targets
The design record covers SDK choices per language, since trace APIs and SDKs are stable in most languages while log SDK maturity varies, along with agent or gateway Collector topology, the target backend, authentication, and redaction rules. Component stability is checked for each Collector component in use. The output is a written design that the security and platform teams approve.
Pilot on a small service group
A small group of services is instrumented and sent through the new Collector pipeline to the target backend. The team checks that traces, metrics and logs arrive with the expected attributes, that Collector resource use fits the planned sizing, and that telemetry volume matches estimates. The output is a pilot report with defects, fixes and a go or no-go decision.
Migrate in waves with dual running
Remaining services move in waves, and old and new agents run side by side for each wave. Service owners compare trace counts, attribute values, error signals and alert behavior between the two paths. The phase closes for each wave when owners sign off the comparison results and any gaps are either fixed or accepted in writing.
Cut over the backend and tested rollback
Exporters are pointed at the target backend through the Collector, and dashboards, alert rules and saved queries are moved and checked against the new data. A rollback path is tested before the switch. The output is a cutover record and updated runbooks that name who operates the pipeline after go-live.
Retire old agents and review
Old agents, libraries and configuration are removed from services, and the old backend is kept read-only for the agreed period. A post-cutover review checks ingest volume, retention, Collector health and open component stability notes. The output is a retirement log and a list of follow-up actions. Ask for a phase plan with dates in the written scope before work starts.

What teams keep in-house and what they outsource

This table sorts the main OpenTelemetry migration work into what most teams keep under their own control and what they often outsource, with the skills each row requires.

Work area	Typical owner	Skills needed
Service ownership and instrumentation intent	In-house	Application language expertise, knowledge of which services and transactions matter most, and authority to change service code
Business meaning of telemetry	In-house	Product and operations knowledge to decide which spans, metrics and log fields reflect real customer journeys and SLOs
Alert decisions and thresholds	In-house	On-call experience, service-level ownership and understanding of incident history for each service
Sign-off on dashboards and alert routing	In-house	Team leadership accountability, familiarity with runbooks and the people who will act on each alert
Telemetry inventory and attribute mapping	Often outsourced	Mapping experience from proprietary APM agents, OpenTracing and OpenCensus names to OpenTelemetry semantic conventions, plus a senior engineer for review
SDK and Collector configuration	Often outsourced	Kubernetes and Collector configuration, exporter setup, pipeline design and secure handling of configuration files
Dual-run comparison and cutover runbooks	Often outsourced	Backend administration, data comparison across old and new pipelines, and runbook writing with rollback steps for each service
Agent removal and exporter security review	Shared, with security review often outsourced	Security review of exporters and credentials, endpoint binding and TLS, plus change control to retire old agents safely

What usually goes wrong

Most migration problems appear while old and new telemetry run side by side. Each card names a failure and the check that prevents it.

Renamed attributes and metrics break dashboards

Span attributes, metric names and labels often change during cutover, so dashboards and alerts keyed to the old names go quiet or show gaps. Map every old attribute, metric and label to its OpenTelemetry name before cutover, and test each alert expression against both names during dual running. Confirm which semantic convention version your backend expects.

Gaps in coverage during dual running

Dual running only helps if both pipelines observe the same traffic. Services moved late, routes that skip the new SDK, and background jobs without instrumentation leave blind spots that can look like quiet periods. Keep a service inventory with an owner and a coverage check per service, and compare request counts between old and new telemetry before retiring anything.

Double ingest from two agents

An old agent and an OpenTelemetry SDK in the same process can export every span or metric twice, raising ingest and storage on the backend. Leftover agents are the second risk: once cutover is declared, they often keep exporting from images or base configurations. Disable each old agent in the deployment, confirm that ingest drops, and remove it from templates.

Mixed sampling and lost trace context

Sampling in an old agent and in the new SDK can disagree, so a trace may keep a child span while dropping its parent. Old agents that do not propagate W3C trace context also break traces at service boundaries. Choose one sampling decision point, apply the same parent-based rule everywhere, and test a request that crosses an old-agent service and a migrated one.

Collector components at different stability levels

Collector pipelines combine components with different stability levels, and each component README states its level. A stable receiver paired with a development-stage processor can still change configuration between releases. Before adopting a component, read its stability level, pin the Collector version, and run a test pipeline before each upgrade.

Unconfirmed OpenTracing and OpenCensus replacements

Custom instrumentation written against OpenTracing or OpenCensus does not always map one to one onto OpenTelemetry, and the replacement API differs by language. Confirm the replacement for each language and each OpenTracing or OpenCensus call path you use, using the SDK documentation for that language. Keep a list of unresolved calls with owners.

How the work changes by starting point

Effort depends on how much the proprietary agent does automatically, such as auto-instrumentation, error capture, profiling and vendor-specific dashboards and alerts.

Inventory what the agent collects: spans, custom attributes, runtime metrics, profiling and which of these your alerts depend on.
Map proprietary attributes and names to OpenTelemetry semantic conventions, and record every gap that needs a manual instrumentation decision.
Confirm SDK and auto-instrumentation maturity for each runtime in use, since trace support is stable in most languages but must be checked per language.
Run both agents side by side for an agreed period, comparing data volume and alert behavior before the old agent is removed.
Check your vendor agreement for license or ingest terms that change when the agent is removed. Confirm this with the vendor.

What you need to provide

Before we can scope an OpenTelemetry migration, we need a clear picture of what you run today. The most useful starting point is an inventory of services and the agents attached to each one: proprietary APM agents, OpenTracing libraries, OpenCensus exporters and any hand-rolled span code. Each agent type maps to a different instrumentation path, so the count and mix of agents drives how much code changes, how many runtimes need testing and how long side-by-side running has to last. Access to the existing APM or tracing backend and its configuration matters just as much. We need read access to agent configuration, sampling rules, custom attribute settings and any ingest filters, because those are the behaviors you will need to reproduce. Dashboard and alert exports belong in the same package. Exported dashboards and alert rules show which signals people actually use, which tells us what must be mapped first and what can be retired.

Telemetry content often contains personal data, credentials or request payloads that someone captured by accident. Please provide your data retention periods and privacy rules for trace, metric and log content, including which attributes must never leave your environment. These rules determine where redaction is applied in the Collector pipeline and whether the old backend's retention settings can be matched. Named service owners are the other input that shapes cost: each service needs a person who can confirm attribute names, approve instrumentation changes and test behavior after cutover.

A change calendar, target backend decisions and a named sign-off owner close the gap between planning and production. Share freeze windows and release dates so rollout waves avoid them. Confirm whether the target is a new backend, an existing one or both, since that choice changes the Collector topology and the effort each path adds. Finally, name the person who accepts cutover for each service. Without that owner, the parallel run has no exit criterion and the old agents stay in place longer than planned, which adds licensing and engineering cost for as long as they remain.

Frequently asked questions

What drives the cost and effort of an OpenTelemetry migration?

The main drivers are how many services and hosts you have, how much of each proprietary agent's behavior your dashboards and alerts depend on, and how many languages and frameworks need instrumentation. Effort also rises with custom instrumentation, attribute mapping between the old and new schemas, and the number of backends you must feed during the transition. The software itself is free and Apache-2.0 licensed, so the spend is on people, Collector infrastructure, and backend storage and ingest. Ask for a quote that itemizes these components and states which parts are one-time and which recur.

Do we have to run the old agents and OpenTelemetry side by side?

Not always, but running both in parallel is the usual way to reduce risk. Dual running lets you compare traces, metrics and logs from the old and new pipelines before you cut over, which helps catch missing spans, renamed attributes and alert gaps. The cost is extra telemetry volume and agent overhead for the overlap period. Whether you need it depends on how critical your alerting is and how much you rely on historical comparisons. Your written scope should state the overlap approach and the criteria for retiring each old agent.

How long does an OpenTelemetry migration take?

Duration depends on the number of services, the languages involved, how many dashboards and alerts must be rebuilt, and whether you change backends at the same time. Changing backends adds a separate workstream and usually lengthens the plan. DeployOpen does not publish a fixed timeline, so the phase plan in your written scope is the reference point for dates and milestones. Ask for the phases, the exit criteria for each one, and which items depend on your own teams' availability.

Can our own engineering team run the migration without a partner?

Many teams can, especially if they already run a Collector and have engineers who know the applications well. The harder parts are usually mapping attributes across old and new conventions, validating that alerts still fire correctly, and retiring agents without gaps in coverage. Before deciding, check whether you have the time and skills for those tasks and who will own the Collector configuration afterward. A written scope lets you compare the work your team would do with the work a partner would take on.

What does the work need from our engineering and operations staff?

You will need application owners to review instrumentation changes, platform engineers to provide Collector hosting and network access, and someone who can approve changes to alerting rules. Staff must also confirm which dashboards are business-critical and which can be retired. Plan time for testing in non-production environments and for on-call reviews during the dual-running period. The exact time commitment should appear in the phase plan of your written scope.

Does OpenTelemetry replace our observability backend?

No. OpenTelemetry is a framework and toolkit for generating, exporting and collecting telemetry. It does not store or visualize data, so you still need a backend for traces, metrics and logs. A migration can keep your current backend and change only how data reaches it, or it can switch backends as a separate project. Decide the backend question first, because it affects Collector exporters, attribute naming and the cost model.

What happens to our existing dashboards and alerts during the migration?

Existing dashboards and alerts usually need review because metric names, labels and span attributes can change when you move to OpenTelemetry semantic conventions. A common approach is to inventory every dashboard and alert, map each signal to its new name, and test the mapped version against live traffic before switching. Alerts should be checked for both false negatives and noise. Confirm with your partner or vendor which mappings will be automated and which need manual rebuilding.

How DeployOpen delivers OpenTelemetry migrations

DeployOpen plans, implements, documents and supports OpenTelemetry migrations inside your own infrastructure, moving from proprietary APM agents, OpenTracing or OpenCensus to the OpenTelemetry Collector and the backends you choose. Engagements are fixed-scope, and the scope is agreed in writing before work starts.

How we scope

The written scope lists each service, agent and telemetry signal that moves from its current tooling to OpenTelemetry.
Attribute mapping from legacy agents, OpenTracing and OpenCensus names is documented before any instrumentation changes.
Scope also names the backends that receive data, the side-by-side period and the retirement criteria for old agents.

How we build

Collector agent and gateway pipelines receive, process and export telemetry to old and new destinations during overlap.
Collector builds include only the components your pipelines need, using the Collector Builder.
Stability of each component is checked against its README before it enters a production pipeline.

How we hand over

Attribute mapping tables, Collector configuration and runbooks are documented in your repositories and systems.
Old agent retirement is tested against a checklist that confirms each signal reaches the new backend.
Configuration stored securely, with secrets kept outside config files and redaction rules for sensitive attributes documented.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Collector and SDK releases, including stability shifts and breaking configuration changes, can be covered under a retainer.
Confirm response expectations, upgrade windows and support boundaries in the written agreement before work begins.

OpenTelemetry migration