Skip to content
MTTL, Mean Time To Learn

BusinessPractitioner9 min read

OpenTelemetry and reversibility: data is portable, operations are not

Sending OTLP to a vendor is not an exit strategy. A six-layer reading of reversibility, a way to measure it (Mean Time To Exit) and why the question becomes urgent in 2027.

For: architects · team managers · finance, risk and compliance · executives and CIOsPrerequisites: Knowing what OTLP and the Collector are: see OpenTelemetry end to end.

Reading mode

OpenTelemetry made observability data portable. It did not make operations reversible, meaning able to change tools without starting from scratch. Sending OTLP, the OpenTelemetry exchange format, to a vendor is not an exit strategy: lock-in simply left the data format and settled higher up, in the queries, the dashboards, the alerts and the way collectors are managed (the relays that receive the data and forward it to storage).

This article offers a six-layer reading of reversibility, a way to measure it rather than assert it and the reasons why the question becomes urgent in 2027.

The misunderstanding: OTLP is not an exit strategy

Section titled “The misunderstanding: OTLP is not an exit strategy”

The argument has become a sales reflex: “we are OpenTelemetry native, so you are not locked in”. It rests on a confusion between two distinct things.

Data portability means that a span (one step of a trace), a metric or a log can be emitted once and read by any compatible backend, meaning any storage and analysis tool. OpenTelemetry really achieved it and that is a significant gain.

Operational reversibility means that a team can change backends without losing its ability to detect, diagnose and steer. It depends on everything that was built on top of the data. OTLP says nothing about it.

An organization that sends OTLP to a vendor, then builds its dashboards, alerts and SLOs (its numeric service objectives) in that vendor’s interface, is no more reversible than before. It is locked in later in the chain, which is more comfortable in the short term and more expensive on the day it leaves.

Where has lock-in moved?

Section titled “Where has lock-in moved?”

Before OpenTelemetry, lock-in started at instrumentation: changing tools meant changing agents and sometimes touching the code. Today it concentrates in four areas that are rarely audited.

  • The query language. PromQL, ES|QL, DQL, KQL, each specific to one tool: every query written in a tool’s language is a line to rewrite if the target backend does not speak it.
  • Operational content. Dashboards, alert rules, SLOs and runbooks (the response procedures) built in an interface rather than in a code repository only exist as long as the contract runs.
  • Processing done on the vendor side. Sampling (keeping only part of the data), enrichment, attribute normalization or anomaly detection performed in the backend disappear with it. The raw data that remains no longer has the same shape.
  • Collector management. A fleet managed from a vendor’s console depends on that vendor, even if every collector speaks OTLP.

None of these areas is covered by the OTLP protocol specification. Yet these four areas are where real reversibility is decided.

Six layers of reversibility

Section titled “Six layers of reversibility”

An observability system is reversible when each of its layers can change provider without dragging the others along. Sovereignty is decided on all six, not only on where the data is stored.

LayerReversible when…Common trap
1. Instrumentationthe code only uses the OpenTelemetry API and SDKs, with the standard semantic conventionsa vendor agent, or a proprietary API called from the code
2. Collectionthe Collector is the upstream version, or a distribution built with OCB from community componentsa vendor distribution that ships components absent from the project
3. Fleet managementthe fleet is managed through OpAMP from a Git repository, with versioned configurationa SaaS fleet management console owned by a vendor
4. Data contractattributes are defined, versioned and checked in continuous integration, for example with OTel Weaverad hoc attributes, normalized afterwards in the backend
5. Operational contentdashboards and alerts live in a repository, in open formats such as Perses or Prometheus ruleseverything is built in the tool’s interface
6. Storage and analysisthe backend is interchangeable and can be hosted by a qualified provider if the context requires itdata and queries in a format that a single tool can read

A few terms from the table. SDKs are the libraries the code calls to produce signals; semantic conventions set the name and meaning of attributes. A distribution is a version of the Collector assembled and shipped by a third party. OCB (OpenTelemetry Collector Builder) is the project’s tool to assemble your own Collector from chosen components. OpAMP is the open protocol for remote agent management. OTel Weaver is the project’s tool to describe and check semantic conventions. Continuous integration means the automatic checks run on every code change. Perses is an open dashboard specification.

Layers 3, 4 and 5 are the most neglected. They are also the ones where you can act without renegotiating any contract.

Spotting façade OTel

Section titled “Spotting façade OTel”

“OpenTelemetry compatible” covers very different realities today. Five questions are enough to sort things out when facing a vendor or an integration offer. They apply to every offer, commercial and open source alike.

  1. Is the collector you get the upstream version, or a distribution that contains components absent from the project?
  2. Are the key functions (sampling, masking, routing) performed in the collector, or only in the backend?
  3. Can dashboards and alerts be exported in an open format, then imported elsewhere?
  4. Does fleet management rely on standard OpAMP, which a server other than the vendor’s could drive?
  5. What happens to the configuration and to the management tool if the vendor changes owner?

The last question is anything but theoretical. On 8 April 2026, Dynatrace announced an agreement to acquire Bindplane, a collection pipeline platform built on OpenTelemetry. The OpenTelemetry configurations stay portable; the tool that drives them changes hands. Fleet governance built on a Git repository and an open protocol does not depend on that kind of event.

Measuring: Mean Time To Exit

Section titled “Measuring: Mean Time To Exit”

A reversibility that was never tested is a hypothesis. I suggest measuring it with a simple indicator: Mean Time To Exit, meaning the time a service needs to get back an equivalent level of operations on another backend. It is a personal proposal, not a standardized indicator.

The exit exercise runs in five steps, on a limited scope:

  1. Pick a representative service, with its dashboards, alerts and SLOs.
  2. Add a second exporter (the component that sends data to a destination) in the Collector towards a target backend, without touching instrumentation.
  3. Replay the operational content from the repository to that backend: dashboards, alert rules, SLOs.
  4. Compare the two environments over a real period of operations: alerts fired, diagnostic queries, coverage.
  5. Note the time spent and list what had to be rewritten by hand, layer by layer.

The result is not just a number. The list of what was rewritten by hand is the most useful deliverable: it points precisely at the layers where lock-in remains. Repeated every year, the exercise shows whether the reversibility debt shrinks or piles up.

Why now?

Section titled “Why now?”

Two European regulations turn reversibility from a good practice into a verifiable requirement. What follows is my reading as an engineer, not legal advice.

DORA. Article 28 requires financial entities to have exit strategies for the ICT services that support critical or important functions. Those strategies must take into account the failure of the provider, the deterioration of the service and the end of the contract. The text asks for exit plans that are comprehensive, documented and sufficiently tested. An observability platform that monitors critical functions may fall within that scope: an exit strategy that was never exercised will hardly convince an auditor.

Data Act. Chapter VI organizes switching between providers of data processing services, which includes IaaS, PaaS and SaaS offers (infrastructure, platform or software rented online). Its rules have applied since 12 September 2025. From 12 January 2027, switching charges disappear, data egress charges included. The financial barrier falls. Only the technical barrier will remain, meaning the one the six layers describe.

So in 2027, leaving will cost nothing in fees, yet it may still cost a lot in rewriting.

Where to start?

Section titled “Where to start?”

There is no need to migrate everything to gain reversibility. Four moves, in this order, shift most of the risk towards assets the organization owns.

  1. Take an inventory of operational content: how many dashboards, alerts and SLOs exist only in an interface?
  2. Put that content in a repository, in an open format, to make it the source of truth rather than a backup copy.
  3. Write the data contract: the expected attributes, their values and their versions, checked in continuous integration before deployment.
  4. Bring processing back into the Collector: masking, sampling and routing decided on the organization’s side, not on the backend’s.

That is the logic I follow with REVERSOTEL, an open source control plane that I wrote: a central point that drives a fleet of collectors through OpAMP from a Git repository. The data contract is versioned there, the operational content is delivered identically to several backends and changing backends comes down to a one-line commit, a single change recorded in the repository.

Conclusion

Section titled “Conclusion”

OpenTelemetry solved the most visible part of the problem. Reversibility cannot be bought with a protocol: it is built layer by layer, by keeping in your own repositories what makes the value of your operations.

When facing a vendor, I would therefore replace “are you OpenTelemetry compatible?” with “how long would it take us to leave?”. An organization that can answer it, with figures, is sovereign over its observability.

Going further

Section titled “Going further”

Sources

Section titled “Sources”

Consulted on 10 October 2026.