Migrating off Highlight.io after the LaunchDarkly acquisition.

What changed at Highlight after the acquisition

Highlight.io launched as an open-source, self-hostable alternative to Sentry and LogRocket combined. The value proposition was direct: one platform, your infrastructure, errors plus session replay plus logs plus traces. The team built genuinely good software. The self-hosted distribution ran on a standard Docker Compose stack, and the codebase was public.

LaunchDarkly acquired Highlight in late 2025. The stated rationale was that feature-flag platforms benefit from understanding how flag changes affect application behavior in production, and Highlight’s session replay and error tracking surface makes that connection visible.

That rationale is coherent. It is also a different product story. Highlight went from “independent observability platform with an open-source self-hosting option” to “observability layer inside a feature-flag platform.” For teams using LaunchDarkly, that integration may be genuinely useful. For teams who had no LaunchDarkly relationship and chose Highlight specifically for its independence, the acquisition changes the contract.

The concrete changes that matter operationally: the self-hosting story has not been actively developed since the acquisition closed. Issues on the self-hosted repository have slowed. The roadmap that was visible on Highlight’s public docs before the acquisition has been absorbed into LaunchDarkly’s planning cycle, which is not public in the same way. None of that makes Highlight non-functional today. It does make the self-hosted path a less confident bet than it was twelve months ago.

Why some teams are reconsidering

The teams this guide is written for are not unhappy with Highlight’s current software. They are unhappy with the uncertainty about where it goes from here.

Self-hosting a tool carries an implicit assumption: the upstream project will continue to release fixes, respond to security issues, and evolve in a direction that serves the self-hosting use case. When a project is acquired by a company whose primary business is not observability, that assumption gets weaker. It may be fine. It may not be. The teams who are reconsidering are doing so because the risk profile changed, not because the software broke.

A second group is reconsidering for pricing reasons. Highlight’s hosted product has been repriced to fit inside LaunchDarkly’s enterprise packaging. Teams that were using hosted Highlight at a startup-friendly price point now face a different conversation with a different sales team.

A third group is reconsidering because they want to simplify their stack. Running Highlight self-hosted is not trivial. It requires ClickHouse, OpenSearch or a compatible search backend, Redis, and a Go ingest service on top of the core application. That is a real operational surface. If the product direction has changed, the cost-benefit of maintaining that surface has also changed.

The four signals Highlight bundled and what replaces each

Highlight gave you four things in one deployment. Migration means choosing what to replace each with. This is the honest map.

Errors

Highlight’s error tracking captured stack traces, fingerprinted issues, and tracked occurrence counts and affected users. It was not as deep as Sentry on the product surface, but it was enough for most teams.

The replacement options are Sentry (self-hosted or hosted), urgentry (self-hosted), GlitchTip, or Bugsink. If you are moving to urgentry, you get 218/218 documented Sentry API operations, errors grouped and deduplicated, OTLP-native trace ingest, alerts via webhook, Slack, and email, and a host that runs in under 100 MB of RAM. The SDK migration from Highlight’s SDK to a Sentry SDK takes roughly an afternoon per service; the two SDKs are not protocol-compatible and there is no shortcut there.

Session replay

This is the hardest replacement. Highlight’s session replay was a first-class product: DOM reconstruction, console log sync, network waterfall, rage-click detection, and a navigation timeline that made it possible to understand exactly what a user did in the two minutes before an error. That product surface is not freely replaceable in the self-hosted world.

The options: stay on Highlight for replay while migrating errors and logs elsewhere; move to PostHog (open-source tier, self-hostable, has session replay); use OpenReplay (open-source, self-hostable, replay-focused); or accept that you are giving up full replay and using urgentry’s partial replay alongside good log and trace coverage to reconstruct user sessions indirectly.

urgentry’s replay story is partial. It ingests replay data, shows session metadata (URL sequence, duration, rage clicks, error count), and provides a scrubber-based player. The full DOM-reconstruction experience that Highlight gave you is not there. If someone on your team watches replays every day to understand customer behavior, that person will feel the gap.

Logs

Highlight collected structured logs and surfaced them alongside sessions and errors. The replacement depends on how you were using them. If you were using Highlight logs as a primary log store for your application, the replacement is an OTel-compatible log pipeline: your application sends OTLP logs to your collector, the collector routes them to Loki, Grafana Cloud Logs, or an equivalent backend. urgentry accepts OTLP logs natively if you want a single backend for errors and logs; the query surface is not a full log management product, but it covers the “what was this service logging around the time of this error” use case.

Traces

Highlight accepted OTLP traces. The replacement is any OTLP-compatible backend: urgentry, Jaeger, Tempo, SigNoz, or Grafana Cloud Traces. urgentry handles OTLP/HTTP JSON natively and correlates traces with errors in the same UI. If your team traces API requests and links those traces to errors, urgentry covers that path without adding another service.

urgentry as the errors replacement

urgentry is a clean-room Go implementation of the Sentry SDK protocol. It accepts any Sentry SDK with a DSN swap as the only configuration change. The compatibility audit covers 218 of 218 operations in Sentry’s published OpenAPI schema. Errors, OTLP traces and logs, attachments, source maps, ProGuard, native crash ingest with minidumps, releases and deploys, alerts, the issue lifecycle, and a Discover-style query language all work.

The relevant numbers for self-hosting: urgentry settles around 52 MB resident memory under steady ingest at 400 events per second. It runs as a single binary against SQLite. The host requirement is a 1 GB VPS, not the 16 GB floor that Sentry self-hosted needs. The operational surface is one file to back up and one binary to upgrade.

Migrating from Highlight to urgentry on the errors dimension involves one SDK change per service. Highlight ships its own SDK (@highlight-run/node, highlight.run, H.init() for the browser, and equivalents for other platforms). Those SDKs talk to Highlight’s proprietary ingest endpoints. They are not Sentry SDK compatible. Switching to urgentry means replacing the Highlight SDK with a Sentry SDK. That is more work than a DSN swap, but it is bounded work: every language Highlight supported has a Sentry SDK, and the Sentry SDK initialization pattern is well-documented.

For a Python service, the change looks like this:

# Before (Highlight)
import highlight_io
H = highlight_io.H(
    "<YOUR_PROJECT_ID>",
    integrations=[],
    record_logs=True,
)

# After (urgentry via Sentry SDK)
import sentry_sdk
sentry_sdk.init(
    dsn="https://<key>@urgentry.example.com/<project_id>",
    traces_sample_rate=1.0,
)

For a Node.js service, the change is similar in shape: remove the @highlight-run/node initialization, add @sentry/node, point it at your urgentry DSN.

The session replay gap

This section deserves more than a table cell. Session replay is the part of Highlight that is hardest to replace, and being vague about it does not help you plan.

urgentry accepts replay data from the Sentry SDK’s replay module (@sentry/replay). It stores the replay payload, tracks the session, and surfaces a timeline view with linked error events and a scrubber-based player. What it does not do is the full DOM reconstruction that Highlight performed server-side: the frame-by-frame DOM snapshot, the synchronized console log overlay, the network waterfall with timing data. Those were first-class in Highlight. They are not present in urgentry today.

If your team uses session replay primarily to understand error context, the urgentry approach covers a meaningful portion of that use case. You get the URL sequence before the crash, the rage-click signal, the approximate time of error within the session, and correlated trace data. That is often enough to close an investigation.

If your team uses session replay to understand user behavior patterns, to watch a customer walk through a confusing flow, or as a primary tool for product and customer success conversations, urgentry’s partial player will feel like a downgrade. In that case, the honest recommendation is to look at OpenReplay or PostHog’s open-source tier for replay, and use urgentry for errors and telemetry separately. That is a two-tool stack, but it is more honest than pretending urgentry closes the gap it does not.

SigNoz is worth naming here too. SigNoz is an OTel-native observability platform, self-hostable under Apache 2.0, with errors, traces, and logs in one place. It does not have full session replay either, but its trace and log product surfaces are more mature than urgentry’s if your team is heavy on distributed tracing rather than frontend error tracking.

The migration playbook

This is the step-by-step. The assumption is that you are running Highlight self-hosted today and want to migrate to urgentry for errors and telemetry, with a separate decision on session replay.

Step 1: Export what matters from Highlight (days 1–2)

Before you touch any configuration, export the data you want to keep. Highlight self-hosted stores data in PostgreSQL and ClickHouse depending on the version. The data you can export that will be useful later:

• Error fingerprints and occurrence history, for audit and retrospective use.
• Session metadata (user IDs, session durations, error counts per session), if you track product metrics against that data.
• Alert rule definitions, so you can reconstruct them in urgentry.

urgentry does not import Highlight’s data format. The export is for your records, not for import. Accept that the history will not carry over and plan accordingly. Most teams find that one to two years of error history in the old tool is rarely queried in practice; the value of an error tracker is in the last ninety days.

Step 2: Stand up urgentry in parallel (days 2–3)

Install urgentry on the host you plan to use for it. The install is a single binary:

curl -fsSL https://urgentry.io/install.sh | sh
urgentry serve --config urgentry.toml

Create your organization and projects in the urgentry UI. Mirror the project structure you had in Highlight: one urgentry project per Highlight project, with the same team membership. Copy the DSN for each project; you will need it in the next step.

Do not shut down Highlight at this point. Both run in parallel through the entire migration window.

Step 3: Replace SDKs one service at a time (days 3–14)

Pick your lowest-traffic internal service first. Replace its Highlight SDK with a Sentry SDK, point the DSN at urgentry, and deploy. Watch urgentry’s Issues page for a day. Confirm:

• Errors arrive and group correctly.
• Stack traces are readable, with function names and file paths.
• Environment and release tags are populated.
• The alert path fires when a new issue appears.

If all four hold, move to the next service. Work in order of traffic volume, lowest to highest. The highest-traffic service should be the last to cut over, after you have two weeks of evidence that urgentry handles your event shape correctly.

For services where Highlight’s SDK also captured OTLP traces and logs, add the OTLP exporter to your existing instrumentation alongside the Sentry SDK. urgentry accepts OTLP/HTTP on the same port as the Sentry SDK ingest. You do not need a separate collector for urgentry’s OTLP path; configure your OTel SDK to export to https://urgentry.example.com/otlp.

Step 4: Run the parallel period seriously (days 7–14)

“Parallel run” means both Highlight and urgentry are live for the same service at the same time. That is not always practical; the Highlight SDK and a Sentry SDK can coexist in the same process, but it adds noise and SDK overhead. The better approach is to run the two tools in parallel at the service level, not the SDK level: some services point at Highlight, some point at urgentry, and you compare the experience across both before moving the remaining services.

The parallel period catches the things a day-one test does not: alert fatigue differences, grouping behavior under real traffic patterns, the absence of events you were used to seeing, and gaps in trace correlation that only show up at scale.

Step 5: Reconstruct alerts (throughout)

Recreate your Highlight alert rules in urgentry as you migrate each service. urgentry supports issue alerts (new issue, issue regression, error rate threshold), slow-transaction alerts, and action targets including email, webhook, and Slack incoming webhook. If you used Highlight’s alert rules heavily, list them before the migration and check each one against urgentry’s alert surface.

Step 6: Handle session replay separately

If you want partial replay coverage from urgentry, add @sentry/replay to your browser SDK configuration when you swap from highlight.run. That gives urgentry the session metadata and the scrubber-based player. If you need full replay, set up OpenReplay or PostHog alongside urgentry at this step, before you cut Highlight off.

Step 7: Shut down Highlight (after the parallel period)

Once every service has been migrated and the parallel period has surfaced no surprises, shut down the Highlight stack. For self-hosted, that means stopping the Docker Compose stack and removing the data volumes. Keep the PostgreSQL and ClickHouse backup you made in step 1 for at least ninety days before deleting it.

A parallel-run period that catches the silent gaps

The most common post-migration failure is not a loud one. It is quiet: an alert that used to fire stopped firing, a grouping that used to merge correctly started splitting, a trace that used to link to an error now has no link. Those gaps do not show up on day one. They show up two weeks in, when someone notices that the error count for a service looks lower than expected.

The parallel-run period is designed to surface those gaps before Highlight is gone. To run it properly:

• Keep a written list of the five to ten error conditions your team cares most about seeing. Confirm each one reaches urgentry during the parallel period.
• Watch urgentry’s ingest metrics for the first week. If a service that previously sent 500 errors per day now shows 50, investigate before attributing it to lower error rates.
• Run a retrospective on any incident that occurred during the parallel period and confirm it was visible in urgentry, not just Highlight.
• Check that source maps and ProGuard mappings are uploaded and resolving correctly. Stack trace symbolication failure is silent: urgentry will show the event, but the stack trace will be minified.

When NOT to migrate

Some teams should stay on Highlight, at least for now.

If you are on hosted Highlight, your LaunchDarkly contract is satisfactory, and you use session replay as a primary tool every day, moving off Highlight means giving up something you would miss. urgentry’s partial replay is not a substitute for Highlight’s replay product. Wait until the self-hosted replay tooling matures, or plan for a two-tool stack before committing to the migration.

If your team already has a LaunchDarkly relationship and the flag-to-error-tracking integration genuinely serves your debugging workflow, the acquisition might have made Highlight more useful for you, not less. This article is not written for that team.

If you rely on session replay for customer success conversations, bug reproduction with stakeholders, or UX research, the session replay gap in urgentry is a real operational loss. Acknowledge it before committing to the migration timeline.

If your Highlight self-hosted installation is stable and well-understood and your team has capacity constraints that make a migration expensive right now, staying put is a reasonable choice. The urgentry installer will be there in six months. The migration is not now-or-never.

Frequently asked questions