Stackify Retrace reaches end of life on March 31, 2027. This guide explains what OpenTelemetry and Helix AIOps with OpenTelemetry are, how they compare with Retrace, and how to plan a move whether or not Helix AIOps is your destination.
As things stand currently:
- Retrace is in maintenance mode. It receives no new features, only hotfixes for high-impact issues and critical security updates, until March 31, 2027.
- Retrace is SaaS only. After the end of life date you cannot log in, send data, or read stored data, so export anything you need to keep before then.
- Helix AIOps with OpenTelemetry is available today. It ties observability data to services, events, and incidents your operations teams may already manage.
- While the Helix AIOps scope differs from Retrace and it is not a like-for-like replacement, it can still provide value for organizations that want application telemetry alongside the rest of their IT operations.
- There is no automated migration path. Any move, to Helix AIOps or anywhere else, means replacing the Retrace profilers and agents with the new platform's instrumentation. For Helix AIOps and many other platforms that is OpenTelemetry; some commercial vendors use their own agents instead.
- OTel instrumentation is not tied to any one vendor's agent. You can try OTel on a single service while Retrace keeps running, which lets you see the results before you commit to anything.
- To learn more about Helix AIOps and get in touch with BMC Helix Sales, visit the BMC Helix observability and AIOps page.
Introduction to OpenTelemetry
OpenTelemetry (OTel) is an open source, vendor-neutral standard for producing and sending telemetry from your applications. It is a Cloud Native Computing Foundation project, and it covers three kinds of signal: traces, metrics, and logs.
OTel is a set of parts that you assemble. The backend, where data is stored, searched, and alerted on, is deliberately not one of them.
| Part | What it does | Who supplies it |
|---|---|---|
| SDKs and auto-instrumentation | Run inside your application and produce traces, metrics, and logs | OpenTelemetry project, per language |
| OTLP | The standard protocol for sending telemetry | OpenTelemetry project |
| Collector | Receives, filters, enriches, and forwards telemetry to one or more destinations | OpenTelemetry project, run by you |
| Backend | Stores, queries, visualizes, and alerts on telemetry | Commercial or open source vendors |
What to know about OTel:
- It is a standard, not a product you log in to. There are no dashboards, alerts, or retention settings until you pick a backend product (such as Helix AIOps).
- It is not zero effort. Teams will still need to enable instrumentation, name services consistently, decide on sampling, and run a Collector.
- It is not equally mature for every code stack. Support differs by language and by signal, so check the current status for the languages you run.
Why it matters as a Retrace customer:
Retrace relies on its own proprietary agents and profilers, which attach to your application and send data only to Retrace. If you move to Helix AIOps or another OpenTelemetry-based backend, OpenTelemetry instrumentation takes the place of those Retrace profilers: you remove them and use OTel instrumentation, a standard that many backends accept, to collect the data instead.
OTel does not capture everything the Retrace profilers did, so see the comparison later in this guide. After that, changing backends is largely a matter of changing where the Collector sends data, and you can send to multiple backends at once while you compare them.
Helix AIOps with OpenTelemetry
Helix AIOps with OpenTelemetry is a solution that accepts OTel traces, metrics, and logs over OTLP and uses them to give Helix AIOps more context about the services your business runs. It is the telemetry layer of the Helix platform, not a standalone application monitoring product like Retrace.
In practice the flow looks like this:
- Your applications send OTel data through an OTel Collector (version 0.128.0 or later) to your BMC Helix tenant using credentials you generate in the BMC Helix portal.
- Helix builds service-to-service topology from the spans and derives Rate, Error, and Duration (RED) metrics from them.
- Those metrics feed Helix Operations Management, where alarm policies raise events that AIOps correlates into Situations. You can also search and inspect traces in BMC Helix Dashboards.
What it does well:
- Turns spans into service-to-service topology and Rate, Error, and Duration (RED) metrics automatically.
- When used with the rest of Helix, puts application telemetry alongside infrastructure events, discovery data, and service context, so operators can see which business services a problem affects.
- Uses AIOps event correlation to group related events into Situations, so teams can work from one Situation instead of many separate alerts.
- Accepts standard OTLP from any OpenTelemetry-instrumented application, so your instrumentation stays portable.
Things worth knowing before you evaluate it:
- Value comes from linking telemetry to the service model, not from the trace viewer alone.
- Today, trace data reaches AIOps Situations through the metrics and events derived from it.
- As a new BMC Helix customer you would first need a Helix tenant. OpenTelemetry is then enabled for that tenant by request through BMC Helix Support.
- Licensing starts from a Helix AIOps Advanced license plus an OTel add-on sized by monthly span volume beyond the starter allotment.
- OpenTelemetry in Helix is supported for SaaS deployments of BMC Helix applications, and it works with any language that OpenTelemetry supports.
- Helix does not detect or mask sensitive data in OTel payloads. Configure your Collector to filter or mask anything sensitive before export.
To see how Helix AIOps turns telemetry and events into operational context, request the BMC Helix Operations Management with AIOps demo. It shows the Situation and event workflow rather than OpenTelemetry data specifically.
How Helix AIOps compares with Retrace
Helix AIOps with OpenTelemetry and Retrace solve different problems for different people, and some Retrace customers could expect a gap in scope, audience, and cost.
| Retrace | Helix AIOps with OpenTelemetry | |
|---|---|---|
| Main users | Developers and small DevOps teams who own the code | IT operations, SRE, and service owners |
| Typical organization | Small and mid-size teams | Enterprises running ITSM, CMDB, and operations processes |
| Core job | Find and fix application problems in one developer-oriented tool | Tie telemetry to services, events, incidents, and changes so operators resolve Situations faster |
| Getting started | Self-service | New Helix tenant, with OpenTelemetry enabled by request |
| Instrumentation | Retrace agents | OpenTelemetry |
| Cost profile | Monthly and Annual subscription model | Enterprise platform license with an OTel add-on for additional usage |
We have not mapped all Retrace features to Helix features one for one, and we do not want to imply a complete match. If a specific Retrace workflow is critical to you, such as error tracking or code-level diagnostics, include it in your pilot (see Setting up a pilot with Helix AIOps below) before you commit.
How OpenTelemetry instrumentation compares with the Retrace profilers
The differences below come from OpenTelemetry instrumentation itself, not from any one backend. Coverage varies by language, framework, and hosting model, so check results against your own applications.
| Capability | Result with OTel auto-instrumentation | Note |
|---|---|---|
| Incoming request tracing and route naming | Comparable | Automatic for supported frameworks |
| Outbound HTTP calls | Comparable | Automatic for supported clients |
| Distributed trace context | Comparable | Standard W3C Trace Context across services |
| Unhandled exceptions | Comparable | Recorded on the span with stack trace |
| Database call spans | Partial | Depends on the database client and version |
| Logging framework integration | Partial | Log bridges vary in maturity by language; validate before relying on them |
| Web server and pipeline stage breakdown | Differs | Needs custom instrumentation |
| Query parameters and row counts | Differs | Often not captured by default; add custom spans where needed |
| Caught (first-chance) exceptions | Differs | Record manually where needed |
| Method-level call trees | Differs | OTel traces boundaries, not internal methods |
| Continuous profiling | Differs | Experimental or still emerging |
OTel on its own has no developer workflows. These workflows depend on the APM backend you choose. If your team depends on any of the gaps above, plan targeted manual instrumentation or keep a supplemental tool for it.
Helix AIOps is a strong fit if:
- You already run, or plan to run, BMC Helix products for monitoring, discovery, or service management.
- Your applications are one part of a larger operations picture that includes infrastructure, networks, and business services.
- You have an operations or SRE team that works from events and incidents rather than from the code.
It is less likely to fit if:
- You are a small or mid-size team and low cost and simplicity matter most.
- Developers are the primary users and need a focused, self-service tool for their own applications.
- You have no need for operations monitoring, such as infrastructure, event management, or incident workflows.
We recommend evaluating Helix AIOps with OTel alongside other APM options, whether OpenTelemetry-based or agent-based, and compare workflow fit and total cost before you decide.
Your options after Retrace
We recommend that Retrace customers choose among the four paths below. Each path replaces the Retrace agents with OpenTelemetry as the common standard, but many commercial vendors use their own agents as well.
There is no simple automated conversion from Retrace to OpenTelemetry or to any other platform. Retrace collects data with its own agents and profilers, so a move to Helix AIOps or to any other backend means replacing them with that platform's instrumentation.
| Path | Best suited to | What it involves | Watch out for |
|---|---|---|---|
| Helix AIOps with OpenTelemetry | Organizations with enterprise operations needs, or an existing BMC Helix footprint | Demo with a BMC Helix representative, then a pilot on one service | New Helix tenant and enterprise license required, broader scope than Retrace |
| Commercial APM platforms | Teams that want a managed tool | Shortlist vendors and trial them with real traffic. Some accept OTLP, while others use their own agents | Pricing varies by data volume, and language support and agent requirements vary by vendor |
| Open source, self-hosted | Teams with platform engineering capacity | Pair open source backends such as Jaeger or Grafana Tempo with Prometheus and Loki, or use an OTel-native option such as SigNoz | You operate, scale, secure, and build alerting for it yourself |
| Dual export during evaluation | Anyone still deciding | The Collector sends the same data to two backends in parallel | Short-term cost and noise while both run |
What is available from BMC Helix now:
- If you want to evaluate Helix AIOps, visit the BMC Helix observability and AIOps page to learn more and get in touch with BMC Helix Sales. A representative will qualify whether Helix AIOps fits your needs and arrange a demo.
- Stackify Customer Support remains available at support@stackify.com through March 31, 2027, including for questions about the end of life.
Setting up a pilot with Helix AIOps
A pilot is a small, time-boxed trial on one service, run alongside Retrace so nothing is at risk. The steps below show how to try Helix AIOps with OpenTelemetry on one service.
- Pick one service. Choose something that matters to the business but has manageable data volume, a clear owner, and consistent metadata such as service name, namespace, and environment. Avoid starting with everything.
- Evaluate and compare the product. For example: can we find the trace for a slow request, see how the service connects to others, and cover the Retrace workflows we rely on (error tracking, alerting, log search) through Helix?
- Get set up. For Helix AIOps, start with a BMC Helix representative to discuss licensing and a tenant.
- Instrument and route. Add OTel instrumentation to the service, run an OTel Collector (version 0.128.0 or later for Helix), and point it at your Helix tenant using the access key generated in the BMC Helix portal. Filter or mask sensitive data in the Collector before export, because Helix ingests what it receives. Keep Retrace running in parallel.
- Decide whether to expand, switch backends, or add custom instrumentation for what is missing.
Planning your move before March 31, 2027
- Take inventory. Note each application, its language and runtime, how it is hosted, which Retrace features your team actually uses (traces, errors, logs, metrics, alerts, dashboards), and your approximate monthly data volume.
- Export what you need to keep. Retrace data does not migrate to any new platform, so export anything required for compliance, audits, or reference. The end of life FAQ links to export guidance for logs and custom dashboards.
- Pilot and evaluate. Add the new platform's instrumentation to one or two representative services: OpenTelemetry for Helix AIOps and many other platforms, or the vendor's own agent where that is what it uses. With OpenTelemetry, route the data through a Collector. Compare your top candidates on the workflows your team depends on. The section above on setting up a pilot with Helix AIOps walks through one way to do this.
- Cut over in waves. Move services in small groups and keep Retrace running for each one until you have confirmed the new setup covers it.
- Decommission. Remove the Retrace agents and confirm nothing still depends on them.
Stackify Prefix Premium has its own end of life notice. For developers who use Prefix on their own machines, its premium features are now available at no cost.