How to migrate from OpenTracing to OpenTelemetry without losing traces
The move from OpenTracing to OpenTelemetry runs through the documented compatibility shim, applied in stages, one group of services at a time. The effort is set by three things: how many services emit OpenTracing spans, how heavily those services rely on baggage, and how many dashboards and alerts read span data as it is today. A team with spans in several services can keep tracing continuous through the move, but only if each stage is planned so that old and new instrumentation report into the same backend without a gap. OpenTelemetry was formed by merging OpenTracing and OpenCensus, two projects that served the same need, and it is a Cloud Native Computing Foundation project. Keep those three drivers in view before you agree on a plan.
OpenTelemetry is an observability framework and toolkit for generating, exporting and collecting traces, metrics and logs. It is an open standard for telemetry rather than a product with its own storage, so it does not store or display anything. Storage and visualization stay with the tools you already run, which is why the migration can keep your existing trace store while the instrumentation changes underneath it. The OpenTelemetry Collector sits between services and those tools. It receives, processes and exports telemetry, and it can run as an agent beside each service or as a gateway that accepts data from many sources. Its repository is licensed under Apache-2.0, so your security team can review the code before it sits in the path of every trace.
Before the first stage, build an inventory with one row per service. Record the language and the OpenTracing tracer in use, whether the service creates or propagates baggage, which downstream services read those spans, and which dashboards, saved queries and alert rules depend on span names, tags or service names. Baggage needs particular attention because its values travel with requests across process boundaries, so a change in how propagation is configured can alter what downstream services receive. Dashboard and alert dependencies are the usual source of surprise: a change in naming can leave a panel empty even while traces still arrive. Assign an owner to each row and name who signs off the cutover for that service.
This section does not give a duration. Timing depends on the inventory, on how many teams own the services, and on how much change control your organization requires for each release. Confirm the schedule against your own inventory, and ask any implementation partner to tie the estimate to the service list and the stages written into the scope. Ask which parts are fixed, which depend on your teams changing their own application code, and which recur after cutover, such as Collector upgrades and periodic review of the Collector configuration. Plan for two early risks: a gap in traces during cutover and a silent break in dashboards. Run old and new instrumentation side by side in a test environment, compare trace counts and span names for the same request path, and keep a rollback step for each service.
What maps cleanly from OpenTracing to OpenTelemetry and what does not
This table compares each OpenTracing concept with its OpenTelemetry counterpart and marks whether the mapping carries over directly, needs code changes, or changes meaning. Read the last column first, because rows that change meaning can break dashboards and alerts even when the code still builds. Span names and attribute keys may differ from what your dashboards expect, so confirm each mapping in the OpenTelemetry documentation for your language before cutover.
| Concept | OpenTracing | OpenTelemetry | Migration effort |
|---|---|---|---|
| Global tracer | A process-wide tracer registered at startup and called from anywhere | A global tracer provider set through the API, with tracers requested by name | Needs code changes |
| Tracer | Created by the tracer implementation chosen for the service | Obtained from a tracer provider configured with resource attributes and exporters | Needs code changes |
| Spans | Started and finished with an operation name and parent reference | Started and ended with a name, span kind and parent context | Maps directly |
| Span context | Holds trace and span identifiers along with baggage items | Holds trace and span identifiers and trace flags, with baggage kept separately | Changes meaning |
| Tags and attributes | Free-form key-value pairs set on a span | Typed attributes, where many keys follow published semantic conventions | Changes meaning |
| Logs and events | Timestamped key-value fields recorded with span.log | Span events with a name and attributes, recorded on the span | Needs code changes |
| Baggage | Propagated with the span context and readable from the span | A separate baggage API, propagated in its own header and not stored on the span | Changes meaning |
| Propagation formats | Inject and extract calls with format-specific carriers chosen per transport | Propagators configured per SDK, with W3C Trace Context commonly used; confirm the default for your SDK | Changes meaning |
| Export and collection | Tracer reports directly to a backend or to a local agent | Exporters send telemetry to the OpenTelemetry Collector, which receives, processes and exports it | Needs code changes |
How the OpenTracing shim keeps old and new instrumentation in one trace
The OpenTracing shim lets code written against the OpenTracing API create spans that the OpenTelemetry SDK records and exports. This is what allows you to move services one at a time. A request that passes from a migrated service into one still instrumented with OpenTracing can appear as a single trace in your backend, so dashboards and investigations keep working while the migration is underway. Treat the shim as a temporary bridge with a defined removal point, and record that point in the migration plan from the start.
Start by confirming which language SDKs provide the shim. Support is set per language, so check the OpenTelemetry documentation for each language your services use. Confirm the exact package names, the versions you will install, and which OpenTracing features each package supports. The supported feature list decides whether your existing instrumentation runs unchanged or needs edits. Trace APIs and SDKs are documented as stable in most languages, including C++, .NET, Go, Java, JavaScript, PHP, Python, Ruby and Swift. Stability of the trace API is a separate question from shim coverage, so check both for every language in your service inventory.
Initialization order is a common source of missing spans. The shim and the OpenTelemetry SDK must be set up before any code requests a tracer. In practice, the startup sequence of each service should install the SDK and the shim before frameworks, middleware, or background workers begin creating spans. Ask each language's documentation how tracers are bound during startup, then build that order into your deployment templates. Add a startup check that emits a test span and confirms it reaches the backend, and run it on every service during the pilot and again after each rollout wave.
Propagation headers must match on both sides of every service boundary. If a migrated service writes trace context in one format and its neighbor reads another, the trace breaks at that hop even though each service records its own spans correctly. Inventory which header formats each side sends and reads, including the handling at proxies, API gateways, and message queues. Agree on the propagation format for the coexistence period before the first service moves, and confirm which propagators the shim uses by default in each language. Then test one call in each direction across every boundary and check that both sides share the same trace ID.
Documented migration paths and the tools to use
Migration runs through three layers: the SDK compatibility shim that keeps existing instrumentation reporting, the Collector that receives and exports the data, and the build and security controls that govern what runs in production. The cards below cover each documented layer and the checks to complete before cutover.
OpenTracing shim in each SDK
Each language SDK provides a compatibility layer that lets existing OpenTracing calls report through the OpenTelemetry tracer. Confirm the shim is documented for the SDK version you plan to run, and list which OpenTracing tracers and propagators your services use, since those determine what must be replaced. Trace APIs are stable in most languages, but coverage of the shim differs by language, so test each service's spans against the old output before you switch.
Collector as agent or gateway
Decide where the Collector runs for each workload. An agent sits beside services or on each host and receives spans locally, which keeps export settings close to the code that produces them. A gateway accepts data from many sources and centralizes processing and export. Many migrations run both tiers. Map every existing tracer export target to one of these roles before you change any service's configuration.
Receivers, processors and exporters
The Collector configuration defines receivers that accept telemetry, processors that transform it, and exporters that send it onward, all wired into pipelines. During migration, the receiver must accept what your existing exporters send, and the exporter must deliver to the backend you already run. Review each processor against your dashboards and alerts, and check each component's stability level in its README.
Collector builder for a minimal component set
The OpenTelemetry Collector Builder compiles a custom Collector from only the components you list. A smaller binary exposes fewer components to misconfigure and fewer to patch. Start from the receivers, processors and exporters your pipelines use, add nothing speculative, and expect to rebuild and retest whenever the component list or the Collector version changes.
Authenticator extensions for receivers and exporters
Authenticator extensions check credentials on incoming connections to receivers, for example through OIDC, and attach credentials to outgoing exporter requests, such as through the oauth2client extension. Migration often opens a Collector endpoint to services for the first time, so decide which identities may send telemetry and which identity the exporter presents before any service points at the Collector. Confirm supported options in each extension's documentation.
Signed releases, checksums and SBOMs
Collector releases ship signed artifacts, SHA256 checksums and SBOM files alongside the builder. Verify each artifact's signature and checksum before deployment, and record the SBOM in your software inventory. Collector v0.163.0 was released on October 16, 2026, after v0.162.0 on September 29 and v0.161.0 on September 16, 2026. Pin one version for the migration, and confirm component stability in each component's README before relying on it.
The migration sequence: inventory, pilot, parallel run, cutover and decommission
The sequence moves OpenTracing instrumentation to OpenTelemetry in five checked stages, so each change can be verified or reversed before the next one starts. Each stage has named owners and a written check that must pass before work moves on.
Inventory every OpenTracing dependency
Your team and DeployOpen list every service, library, span name, tag, baggage key, dashboard and alert that depends on OpenTracing data. Each service owner confirms their entries, and the inventory records which team will change each item. The inventory is complete when every span name and baggage key has a mapped OpenTelemetry equivalent or a documented reason to drop it, and the owners have signed off. Your team provides repository access, dashboard and alert exports, and named owners. DeployOpen delivers the inventory and the mapping table.
Pilot one low-risk service
Choose one service with a small blast radius and few downstream consumers, then move it to OpenTelemetry using the compatibility shim for its language. Confirm that traces arrive end to end, with parent-child links, expected span names and baggage intact. Baggage propagation is where mismatched keys usually surface, so check it on every downstream call. Your team supplies the service, a test environment that reflects production request patterns, and a reviewer for trace output. DeployOpen implements the pilot change and delivers a trace comparison report. The pilot is done when the traces match the mapping table and the owner accepts them.
Run old and new telemetry in parallel
Services export both OpenTracing and OpenTelemetry data so the two streams can be compared on the same requests. Dashboards and alerts stay on the old names while teams build parallel panels against the new ones. Your team provides the backend capacity for the duplicate data and agrees with DeployOpen how long the comparison runs before cutover. DeployOpen configures the Collector pipelines, reconciles span counts and attribute values, and records each difference with its cause. The stage closes when every difference is explained and accepted by the owners.
Cut over dashboards, alerts and sampling
Each team makes one planned change that moves its dashboards, alert rules and sampling configuration to the OpenTelemetry names. Changes are scheduled per team so that no team changes its telemetry and its consumers at the same time. Alert thresholds are checked against the parallel-run data before the switch, because renamed attributes can quietly stop a rule from matching. Your team approves the change window and runs the on-call handover. DeployOpen prepares the change sets, rollback steps and before-and-after checks. Cutover is complete when each team's alerts fire on test conditions under the new names.
Decommission the OpenTracing dependency
The OpenTracing libraries, shim configuration and old export paths are removed only after the old data path shows no consumers. Use the inventory and your backend's query records, if it reports them, to confirm that nothing still reads the old names. Ask your backend vendor whether it can report queries against old attribute names before relying on that check. Your team confirms the retention policy for historical OpenTracing data, which stays available under that policy. DeployOpen removes the dependencies in a tracked change, updates the runbooks and delivers the final inventory with a closeout record. Decommission is done when the inventory shows no remaining OpenTracing references and the owners sign the closeout.
Baggage pitfalls that break context in migrated services
The most common way a migration to OpenTelemetry breaks request context is not a missing span but a missing or altered baggage entry. During the move, services may run OpenTracing and OpenTelemetry side by side, and the two APIs do not always carry baggage in the same headers or with the same encoding. A key set by an OpenTelemetry service may arrive at an OpenTracing service in a form it does not read, or the reverse. Before you cut over any service, list every baggage key your platform relies on, record which header carries it on each side of the bridge, and confirm the value format each service expects.
Baggage is also easy to leak. Values placed in baggage can be copied into span attributes, log records or metric labels by instrumentation, middleware or custom code, and from there they reach the Collector and your backend. Customer identifiers, account numbers or session tokens are the usual examples. Review each baggage key for sensitivity, decide whether it should propagate at all, and check whether any instrumentation in your stack copies baggage into telemetry by default. Treat this as a data classification question for your security and privacy owners, not only an engineering detail.
The Collector's redaction processor is the control to plan for when baggage-derived values reach telemetry. It can remove or mask attributes that match configured rules, which gives you a second line of defense if an application copies a value you did not expect. Redaction is only as good as its rules, so write them from your data inventory, test them with sample telemetry that contains realistic-looking but synthetic identifiers, and confirm the processor's current behavior and configuration options in the Collector documentation for the release you deploy. Redaction does not replace removing sensitive values from baggage at the source.
OpenTelemetry's Collector security guidance applies directly to telemetry that carries customer identifiers. Store the Collector configuration securely, since it may hold credentials for exporters. Encrypt traffic between services, the Collector and the backend, and use authentication on receivers and exporters, for example through authenticator extensions. Build the Collector with only the components you need, using the Collector Builder, so that unused receivers and processors do not widen the attack surface. Server components bind to localhost by default since v0.110.0, so confirm any change to listen addresses is deliberate and reviewed.
Test baggage at every service boundary during the pilot stage, not only at the entry point. Send a request with known baggage keys through each path that a real transaction takes, including services that have not yet migrated, message queues, and any proxy or gateway that sits between them. Check that each key arrives unchanged, that no service drops or rewrites the baggage header, and that no sensitive value appears in span attributes or logs. Confirm the header names, propagation formats and size limits for your language in its OpenTelemetry and OpenTracing documentation, because behavior differs between SDKs and versions, and record the results so they can be repeated before each further cutover.
What drives the cost and duration of the migration
This table lists the factors that raise or lower migration effort and whether each one is paid once or keeps costing money. Use it to see which parts of your estate need inventory before anyone can quote, and to ask for the specific artifacts that make a quote comparable. No single driver sets the outcome on its own, so read the rows together against your own environment.
| Driver | Why it changes effort | One-time or ongoing | What to ask for in a quote |
|---|---|---|---|
| Number of services and languages | Each service and language runtime needs its own instrumentation change, build update, test run and deployment, so effort scales with the count of distinct stacks | One-time for the conversion, but each new service added during the rollout adds work | A written inventory of services by language and framework, with a named pilot service |
| Direct OpenTracing API calls versus library use | Direct calls to the OpenTracing API must be rewritten by hand, while services that rely on auto-instrumentation or framework libraries may need only configuration and version changes | One-time | A code scan or inventory that separates direct API calls from library-driven spans |
| Depth of custom baggage use | Baggage crosses service boundaries and has to be re-mapped, tested and checked against downstream consumers, which is where most subtle propagation faults appear | One-time to map, with a recurring check if new services read or write baggage | A list of every baggage key, its producers and consumers, and the expected behavior during mixed-version traffic |
| Dashboards and alert rules keyed to span or attribute names | Renamed or restructured attributes break queries silently, so each dashboard and alert must be found, re-pointed and validated against live data | One-time re-pointing, then ongoing review as dashboards change | The list of dashboards and alert rules to be re-pointed, with owners and the data sources each one reads |
| Sampling configuration | Sampling rules set in one place may behave differently after conversion, so volumes and retained traces need comparison before the old setup is removed | One-time to align, with ongoing tuning as traffic changes | The current sampling settings per service and the target settings, with a plan to compare trace volumes during the parallel run |
| Environments that need a parallel run | Running both instrumentation paths side by side in each environment doubles the telemetry paths to verify and extends the period of operating two setups | One-time setup per environment, with ongoing operation for the length of the overlap | The list of environments, the order in which they will be converted, and the criteria for ending the parallel run |
| Collector pipeline changes | New receivers, processors and exporters must be configured and secured, and the Collector configuration needs version control and review | One-time build, then ongoing maintenance as Collector versions change | The Collector configuration design, the components to be included, and the release version to be pinned |
How long OpenTracing and OpenTelemetry can coexist in one system
The compatibility shim lets services instrumented with OpenTracing and services instrumented with OpenTelemetry run in the same system during the transition, so a trace can cross both. The shim does not set a safe duration on its own. How long the two can coexist depends on three factors: the supported status of OpenTracing and the shim in each language your estate uses, your team's ability to operate two telemetry data paths at once, and the cost of sending duplicate telemetry to your backend. Work through all three before you set a plan. Start with support status. Confirm in the official OpenTelemetry documentation whether the OpenTracing bridge or shim is available and maintained for each language you run, and record the version and date you checked. Also confirm the status of OpenTracing itself for each language. Do not assume that a language with a working shim today will keep it. Your overall window is set by the language with the weakest support, so list the languages in your inventory and flag any with a missing or lagging shim before the migration schedule is written.
Next, assess whether your team can run two data paths. While both APIs are in use, each affected service carries two instrumentation libraries, two sets of configuration, and potentially two sampling decisions. Dashboards and alerts may draw from either path, so engineers must know which signal comes from where when a trace looks incomplete. Count the people who can debug both paths during an incident. If that number is small, the coexistence period should be shorter, and the migration should move in smaller service groups. The cost of duplicate telemetry grows for as long as both paths run. Your backend may charge for ingested data, stored data, retention, or licensed users, and duplicate spans or metrics raise each of these. Ask your backend vendor how it bills for duplicate data and what the contract says about overages. Plan for the cost to recur every billing period while both paths are live, and track it against the migration plan. The cost is driven by telemetry volume, retention length, and the number of services still on both paths.
The parallel run should have a fixed end date, agreed and recorded in writing with a named owner. Attach exit criteria to that date, such as every service in the inventory emitting OpenTelemetry, dashboards and alerts ported and verified, and the shim removed from the build. Decide in advance what happens if a criterion is not met. The safer choice is an escalation to the sponsor with a revised plan, not a silent extension that adds recurring cost without a decision. Illustrative example: a team might set one cutover date per service group and review each group's exit criteria before the next group starts. Confirm the end date, owner, and criteria with your stakeholders before any service is changed.
What breaks dashboards and alerts during the move and how to prevent it
Most breaks during an OpenTracing move are not outages. They show up as dashboards with different numbers, alerts that stop firing, or telemetry that never reaches the backend. The five risks below cover the usual causes, and each one maps to a check in the parallel run or the cutover checklist.
Renamed semantic convention attributes
Tags written for OpenTracing and the attribute names defined by OpenTelemetry semantic conventions do not always match. Dashboard filters, query labels and alert rules that reference the old keys can go silent without raising an error. During the parallel run, compare the attribute keys each service emits through both pipelines for the same requests. Update queries and alert rules to the new names, and list every renamed key in the cutover checklist before traffic moves.
Span kind and status code changes
Error rate panels usually count spans with an error status or an HTTP error tag. OpenTelemetry sets span kind and status explicitly, so a migrated service may mark spans as errors under different conditions, and the error rate can move with no change in behavior. In the parallel run, compare error counts per service and per span kind over the same time window. Record each rule that differs in the cutover checklist and agree the intended definition with service owners before alerts are repointed.
Sampling shifts latency percentiles
Percentiles calculated from sampled spans depend on which requests were kept. If the old tracer and the new SDK or Collector use different sampling rates or policies, p95 and p99 can move even when the services are unchanged. During the parallel run, use the same sampling configuration in both paths where possible. Document the sampler and rate next to each latency panel in the cutover checklist, and confirm with the backend team whether those panels are built from spans or from metrics.
Baggage lost at service boundaries
Teams often use baggage to carry tenant, region or customer tier values across calls so that traces can be filtered by them. A mixed fleet can break this if one service still propagates the old format, or if a proxy, gateway or message queue drops the headers. Dashboards that group by these values then show missing or unknown groups. Inventory each baggage key in use, follow it through every service hop during the parallel run, and add a check to the cutover checklist that confirms the propagation format on both sides of each boundary.
Collector endpoints exposed to the network
Collector receivers accept telemetry on network ports, and teams often open them widely during a parallel run so that both pipelines can reach them. Since v0.110.0, server components bind to localhost by default, so any receiver that services on other hosts must reach needs its listening address set on purpose. Set each endpoint to the interface it needs, add authentication where the security guidance recommends it, and record in the cutover checklist which addresses are open and which networks can reach them.
Questions buyers ask before hiring outside help for this migration
How much does an OpenTracing to OpenTelemetry migration cost?
Cost follows from the written scope, and DeployOpen does not publish a price list. The main drivers are the number of services and languages that carry OpenTracing instrumentation, how much custom span, baggage and propagator code exists, how many Collector pipelines you need, and how many dashboards and alerts must be reworked. Costs fall into one-time work (inventory, instrumentation changes, Collector setup, testing and cutover) and any recurring support or retainer you choose to add. Ask the quote to list each service, the target backend, the change-window plan, the acceptance tests and the handover deliverables, so you can compare it with an internal estimate line by line.
How long does a migration like this take?
Duration depends on scope, and no timeline is set here, so confirm any estimate in writing. The biggest drivers are the number of services, the languages in use, how much custom instrumentation exists, and whether teams can move one service at a time. Dashboard and alert rework often takes longer than the code change, because renamed attributes can break queries that your teams depend on. Approval cycles for production change windows and the number of environments (development, staging and production) also add time. Ask for a plan that sequences services, names an owner for each milestone and identifies which steps depend on your team's availability.
What does our team need to provide during the migration?
Plan on named people from several groups. Service owners confirm instrumentation scope, approve changes to their code and agree on rollout order. Dashboard and alert owners review which panels and rules reference OpenTracing-era names and approve the replacements. Platform or SRE staff provide access to clusters, the environment where the Collector runs and the trace backend. You also need a change window for each production cutover and someone who approves rollback steps before each one. Ask the written scope to list each role, the expected time each person must commit, and the decision points where sign-off is required.
Can our own engineers complete this migration without outside help?
Yes, an internal team can do this work if it includes people who know the services, the telemetry backend and the Collector. The decision turns on skills, available time and how much production risk the team can absorb during cutover. Check whether your engineers have built distributed tracing before, whether they can review semantic convention changes against existing dashboards, and whether they can configure Collector authentication and redaction. Outside help is worth considering when the service inventory is large, many teams must change together, or internal capacity is already committed. Whichever route you choose, write down the scope, the owners and the acceptance tests before work starts.
Can OpenTracing and OpenTelemetry run together during the migration?
Coexistence is the usual way to move services one at a time, but whether a compatibility shim covers your languages and SDK versions must be confirmed against the current OpenTelemetry documentation for each language you run. OpenTelemetry was formed by merging OpenTracing and OpenCensus, so the two projects share history, but that does not guarantee every combination works. Trace continuity is the main risk: a request that crosses a service still on OpenTracing and a service on OpenTelemetry must propagate context correctly, or traces will break at the boundary. Ask how long coexistence will last in your plan and what exit criteria end it, because no coexistence period is set here.
Will the changed semantic conventions break our dashboards and alerts?
They can, so inventory every dashboard and alert before changing any code. Semantic conventions define the attribute names used for spans, metrics and resources. When names change, queries can return empty results without raising an error, and alerts built on missing series may stop firing silently. Compare the attribute names your OpenTracing spans emit with the names your OpenTelemetry instrumentation produces, in staging, against each backend you use. Keep a list of each query, its owner and a known test event that should trigger it. Confirm which convention versions apply to each signal in the current OpenTelemetry specification before you map old names to new ones.
Does DeployOpen issue a compliance attestation for telemetry work?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that role. For telemetry work, useful evidence can include Collector configuration kept under version control, documented access controls on telemetry endpoints, redaction rules for sensitive attributes, and records of which data each pipeline exports. Ask your auditor which evidence they expect before scoping begins. Then ask DeployOpen to name in the written scope which artifacts will be delivered, and confirm which Collector security practices, such as authentication on receivers and encryption on exporters, your assessor requires.
What should a written scope for this migration cover?
A written scope should name the services, languages, trace backends and environments involved. It should list the instrumentation changes, Collector pipelines, dashboard and alert updates, testing approach, cutover plan, rollback steps and handover deliverables. It should also state what is excluded, such as application code your teams own or upgrades to the backend. Ask who signs off each milestone and which acceptance tests prove the work is done. Request recurring support options as a separate line from the one-time migration. DeployOpen implements and supports self-hosted platforms in infrastructure you control, so confirm whether the Collector and backend will run in your cloud account, data center or air-gapped network.
How DeployOpen works on this
DeployOpen plans and implements Migrate from OpenTracing to OpenTelemetry inside your own infrastructure, starting from a written scope that lists your OpenTracing services, the backends and alerts that depend on them, and the order of cutover. Work is delivered in stages with testing, documentation and handover to your team, and ongoing support is available as a retainer. OpenTelemetry is vendor-agnostic and is not an observability backend, so storage and dashboards stay in the tools you choose.
How we scope
- The written scope lists every service with OpenTracing instrumentation, its language, and its current tracer setup.
- It names the backends, dashboards and alerts that consume the traces, so changed names are caught before cutover.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.
How we build
- Move services to OpenTelemetry in the documented shim order, one service at a time.
- Review baggage use in each call path, since baggage handling needs explicit checks while both APIs run.
- Compare traces from old and new instrumentation in staging before each cutover step.
How we hand over
- A migration runbook recording the order, the completed services, and the rollback step for each one.
- Collector configuration kept in version control, with the redaction processor settings documented for sensitive attributes.
- A dashboard and alert mapping table listing each old and new name, with owners named for sign-off.
How we support
- Track Collector release notes and component stability levels, and plan upgrades against the components your pipelines use.
- Agree the coexistence window with your teams and record its end date in the runbook.
- Ongoing retainer support covers Collector upgrades, configuration changes and dashboard fixes after handover.
