How to export your data from Honeycomb before the contract ends
Most of the value that leaves Honeycomb with you is the instrumentation you own and the queries you can rebuild. Raw event history is short-lived, and what you can export depends on your plan and API access. If a renewal, a pricing change or a data residency concern has started your exit, plan around those two facts first. Your OpenTelemetry instrumentation lives in your code and collector configuration, so it moves with you regardless of vendor. The events already stored in Honeycomb are a different matter. They expire, so every week you wait is history you may not be able to recover from that platform.
Start by confirming what you can take out. Honeycomb's Query Data API sits on the Enterprise plan, so teams on other plans should not assume programmatic export is available. Events expire after 60 days, which sets the practical limit on any historical export. Boards, triggers and SLOs do not move automatically: you recreate them in the new backend, so keep a written inventory of each one, including its query, threshold, owner and the people who receive its alerts. Before you rely on any export path, confirm the export formats, row limits and rate limits in Honeycomb's documentation and with your account team, since this page does not set them.
Dual-shipping is the step that matters most. Because Honeycomb ingests OpenTelemetry, you can configure the OpenTelemetry Collector to send the same telemetry to Honeycomb and to your self-hosted backend in parallel. Define one exporter per destination under exporters and reference both in the same pipeline. The Collector is vendor-agnostic and can run as an agent next to services or as a gateway that accepts data from many sources, so the change stays in collector configuration. Start early. Once both backends receive the same data, the new system builds its own history while Honeycomb is still in place, and you do not have to wait for the contract to end to begin accumulating queryable data. Check that the new backend's retention matches your audit and incident review needs before you cut over.
What you can export from Honeycomb and how
This table lists each type of Honeycomb data you may need to take out before leaving, the method for getting it, and the plan or limit that applies. Check the format and rate limit cells against Honeycomb's documentation before you plan a cutover, because those details were not confirmed for this page. The main takeaway is that your OpenTelemetry instrumentation is the asset you fully control, while historical events and dashboard configuration need deliberate handling.
| Data type | Export method | Format | Plan requirement and limits |
|---|---|---|---|
| Event data within the 60-day retention window | Query Data API | Confirm in Honeycomb's API documentation | Enterprise plan only. Events expire after 60 days, so older data cannot be pulled. |
| Query results | Query Data API, run against saved or ad hoc queries | Confirm in Honeycomb's API documentation | Enterprise plan only. Confirm rate limits and result size caps before a bulk pull. |
| OpenTelemetry instrumentation and Collector configuration | Copy from your own repositories and deployment configs | Standard OpenTelemetry SDK and Collector configuration files | No vendor plan needed. You own this code, and it can point at SigNoz or Grafana without rewriting instrumentation. |
| Boards, triggers and SLOs | No bulk export path confirmed here. Recreate by hand, or confirm any API access in Honeycomb's API documentation | Recreated in the new backend, not copied | Confirm plan access for any API route. Keep a written inventory of each board, trigger and SLO before you start. |
| Historical traces beyond 60 days | Not available from Honeycomb once expired | Not applicable | Only data you forwarded elsewhere before expiry survives. Dual-shipping OpenTelemetry data starts that history early. |
What does not export from Honeycomb and what to do instead
Honeycomb's stored events, boards, triggers, SLOs and access settings do not move to a new backend on their own. Each item below needs a deliberate workaround, and most of them start during the dual-shipping period, before you cut over.
Events older than the window
Honeycomb events expire after 60 days, so anything older than that is gone from Honeycomb once it ages out. The new backend only holds what it received, which means history starts building from the day OpenTelemetry data first reaches it. Start dual-shipping early enough that the new backend has the incident and seasonal patterns your team needs. Export any event data you need to keep during the dual-ship period, and store it in object storage you control. Confirm current retention behavior and any export options for your plan with Honeycomb before you rely on them.
Boards that must be rebuilt
Honeycomb boards are not imported into SigNoz, so every dashboard your on-call and product teams rely on has to be recreated. Start with the boards used in incident response, then rebuild the rest by priority. SigNoz dashboards can be built with its Query Builder, PromQL or ClickHouse SQL, so pick the query style that matches each panel's logic. Keep a list of board names, owners and the questions each board answers, so nothing important is dropped in the rebuild.
Triggers and alert logic
Triggers from Honeycomb do not carry over, and their thresholds, query conditions and notification routes must be written again in the new backend. Export each trigger's query, threshold, evaluation window and recipient list into a version-controlled file before you turn Honeycomb triggers off. Then recreate them in SigNoz and compare alert behavior during the overlap period. Alertmanager handles deduplication, grouping and notification in the SigNoz architecture, so check how routing and silencing map onto your current on-call tools.
SLO targets and definitions
SLOs must be recreated, and the targets, time windows and the SLI query behind each one need to be written down first. Record each SLO as a plain-text definition in a repository, including the numerator and denominator, the window and the owner. Recreating from that file makes it possible to check that the new SLI matches the old one on the same traffic. Expect some differences if the query language or sampling differs between the two backends, and document any change in target before you publish it.
Team, user and access settings
Honeycomb users, teams and their access to datasets do not transfer to SigNoz. Inventory who needs read, edit and admin rights, and map those roles to SigNoz users before cutover. If you plan to use single sign-on, check which features your SigNoz edition includes: SSO is listed on every plan including Community, while SAML is limited to the Teams and Enterprise plans. Confirm the exact role model with the SigNoz documentation for your version, and record the mapping in your access review.
Saved queries and investigation context
Saved queries, bookmarked investigations and the query history that engineers use during incidents are not portable. Ask your team to list the saved queries they depend on, and copy the query logic into a shared runbook alongside the incident they support. Rebuild the most used queries in SigNoz, and keep the originals as text in your repository. Tell the reader to confirm with Honeycomb which saved-query data remains accessible in your account before you close the subscription, and whether any export format exists for your plan.
The export sequence, in order, with a verification gate at each step
This sequence moves your Honeycomb telemetry, history and alerting to a new backend without losing the data you must keep. Each step ends with a check that the next step depends on, so you can stop, roll back or continue with evidence at every point.
Inventory boards, triggers, SLOs and datasets
Export a written list of every Honeycomb dataset, board, trigger and SLO, along with the queries behind each one. Record the owner, the purpose and any on-call rotation that depends on each alert. Engineers who built these assets should review the list, because boards and alerts often contain queries that nobody has read in months. This step is done when the inventory is stored in your change system and every item has a named owner and a target status of recreate, retire or archive.
Confirm your plan and Query Data API access
Check your Honeycomb plan and whether the Query Data API is included, since that API sits on the Enterprise plan. Ask your account team in writing what the contract covers for data export, including formats and any limits. Without API access, pulling data depends on manual steps in the interface, which is slower to run and harder to audit. This step is done when the plan, API availability and export terms are recorded in the migration file and approved by the budget owner.
Deploy a Collector that dual-ships to both backends
Platform engineers deploy an OpenTelemetry Collector that receives OTLP from your services and exports to Honeycomb and the new backend at the same time. Set the exporters from the Collector configuration documentation, and keep credentials in environment variables or a secrets store. Check each component's README for its stability level before production use. This step is done when test spans arrive in both backends with matching service names and attributes.
Let history build in the new backend
Keep dual shipping running for as long as your business needs history in the new backend. Honeycomb events expire after 60 days, and data sent only to Honeycomb will not appear in the new backend, so the overlap period sets how much history you can compare later. Agree a retention target with the owners of audit, incident review and compliance needs. This step is done when the target is written down and the new backend holds data from every service in scope.
Export the query results and events you must keep
Use the Query Data API, or the export path your contract allows, to pull the query results and event data that audit, incident review or compliance requires. Name the datasets, time ranges and fields in each request, and record a row count or checksum for every file. Confirm with the compliance owner that the exported set meets their requirement before the source data ages out. This step is done when each file opens, matches its recorded count and is stored with the request that produced it.
Recreate boards, triggers and SLOs in the new backend
Rebuild each board, trigger and SLO from the inventory using the query tools of the new backend. Keep the original names and thresholds so on-call staff recognize them, and document every change in meaning or behavior. Where a query cannot be expressed in the new tool, note it as an open item instead of approximating it silently. This step is done when each inventory item has a counterpart record and the owner has signed off on the alert routing.
Compare results between both backends
Run the same queries against Honeycomb and the new backend over an identical time window. Compare counts, error rates, latency percentiles and SLO status, and expect differences from sampling, timestamp handling and attribute mapping. Write each difference down with its cause. This step is done when every SLO and key board matches within the tolerance the service owners agreed in writing, and each unexplained difference is resolved.
Cut over exporters and archive exported data
Remove the Honeycomb exporter from production Collector pipelines so services send telemetry only to the new backend. Keep the Honeycomb path configured for a rollback window agreed before cutover. Then archive the exported data, the inventory and the comparison records in your retention store with access controls. This step is done when Honeycomb receives no production traffic, the archive passes its checksum verification and the owner closes the migration file.
Which export path applies to your Honeycomb plan
If your Honeycomb agreement includes the Query Data API, you can script pulls of query results and store them in your own infrastructure on a schedule. This gives you the most control over what history leaves Honeycomb, but only for the queries you define and only for the period you pull before data expires.
- Timeline: Start scheduled exports now, because events expire after 60 days and anything not pulled by then cannot be recovered through the API.
- History at risk: Raw events older than 60 days are gone from Honeycomb, so the history you keep is limited to what your export jobs already captured.
- Definitions: The API covers data, not your boards, triggers and SLOs, so record their settings by hand and plan to recreate them in the new backend.
- Written requests: Ask Honeycomb to confirm in writing the scope of the API, the row and rate limits, how exported results are structured, and the support path when a job fails.
- Test restore: Run each export job against a sample dataset and confirm you can query the stored copy before the cutover.
Before relying on this path, confirm that every dataset you need is covered by a job that is running and producing readable output.
Without the Query Data API, the history you can keep is the telemetry you already hold outside Honeycomb. The practical route is dual-shipping: send the same OpenTelemetry data to Honeycomb and to the new backend, so the new backend builds its own history from the day the export starts.
- Timeline: Dual-shipping only builds history from the day it begins, so start it as early as your change process allows to give the new backend more data when you switch.
- History at risk: Honeycomb data older than 60 days that you did not copy elsewhere cannot be rebuilt, so check now which datasets you have already saved.
- Collector fan-out: Configure one OpenTelemetry Collector pipeline with two exporters, one for Honeycomb and one for the new backend, following the OpenTelemetry Collector configuration docs, and keep the Honeycomb path until parity is confirmed.
- Written requests: Ask Honeycomb to state in writing which export options your plan includes, whether any bulk export exists, and how long your data remains available after cancellation.
- Your own copies: Store any saved query results, exports or screenshots in object storage you control, with a retention rule that matches your audit and incident review needs.
Before you choose a cutover date, list the datasets missing from your copies so you know which history will start fresh.
Many accounts span several environments, teams and datasets, and entitlement can differ between them depending on how the contract was written. Do not assume that one enterprise agreement covers every environment, and do not assume that a non-enterprise account has no options. Confirm each environment separately before you plan the export work.
- Inventory: List every environment, team, dataset, board, trigger and SLO, with a named owner for each.
- Entitlement check: Ask Honeycomb in writing, per environment, whether the Query Data API is included in the agreement that applies to it.
- Shared datasets: Identify telemetry that several teams query, since an export set up for one team may miss the queries another team depends on.
- Contract timing: Find the renewal and end dates, because the practical window to export can close when the agreement ends, not only when data expires.
- Escalation: Name an internal owner who can escalate to Honeycomb if the written answers do not match what the account shows.
Record each answer in the migration plan so that every export path has a documented owner and a documented date.
How to verify that the new backend holds your data
Before you cut over, prove that the new backend holds what Honeycomb holds for the same window. Pick a time range that is still inside Honeycomb's 60-day event retention, then compare span and event counts for that window in Honeycomb and in your self-hosted backend. Run the same filter on service name and environment in both tools, since a count mismatch is most often a routing or filter difference rather than data loss. Expect small differences from sampling, late-arriving spans and clock skew at window edges, and record any gap you cannot explain before you accept the result. Ask your team to repeat the comparison on several windows, including a peak-traffic period, because a single quiet hour proves little.
Check that the data is intact, not only present. Sample a set of traces from Honeycomb, note their trace IDs, and confirm the same IDs appear in the new backend with the same parent-child structure, span names, durations and status codes. Compare the attributes you rely on for queries and alerts, such as service.name, http.route and any custom attributes your boards filter on, and confirm their types and values survived the pipeline. Then review the Collector configuration for silent loss: check memory_limiter and any filter, tail_sampling or attributes processors for rules that drop or rewrite data, and check the exporter's queue and retry settings for dropped batches. The Collector configuration best practices page is a useful checklist. Run the Collector's own telemetry metrics on the gateway during the test, since dropped or refused spans show up there even when the application sees no error.
Treat the Collector as software you are deploying, so put its release through your change process. The OpenTelemetry Collector repository is licensed under Apache-2.0, which you should confirm against the license file in the version you deploy. Pin the exact release version in your image or package manifest rather than using a floating tag, and confirm that version on the Collector releases page before rollout. Verify the artifact checksums and signatures the release publishes, and keep the SBOM with your change record so security reviewers can see which components are in the build. Confirm the contrib distribution contains only the receivers, processors and exporters your configuration uses, and document which component stability levels you accepted. Only after counts, IDs, attributes and Collector health all pass should you stop dual-shipping and retire the Honeycomb exporter.
What to plan before the Honeycomb renewal or termination
Leaving Honeycomb is mostly a question of sequence: what you can still pull out, when the contract stops, and how long the new backend needs to hold useful history. The cards below cover the dates to pull from your contract, the access you must keep, the parallel run, the people who will own the stack afterward, and the written assurances you should request before you stop paying.
Confirm notice and renewal dates
Pull the notice period, auto-renewal terms and the exact end date from your Honeycomb order form or master agreement before anything else. Many teams discover that the notice deadline falls well before the renewal date, which changes when the migration must be finished. Ask your account contact to confirm these dates in writing, including how the billing period ends if you stop sending data partway through a term.
Map the export window to the contract
Events in Honeycomb expire after 60 days, so anything older than that is gone regardless of your contract. Work backward from your planned cutover date to find which history you can still query and export, and decide what must be saved while it remains available. Confirm with Honeycomb whether any retention extension or Enterprise add-on changes that window for your account.
Secure Enterprise API access first
The Query Data API sits on the Enterprise plan, so if you need programmatic access for a final export of boards, queries or data, you must keep that entitlement until the export is complete. Downgrading or letting the Enterprise term lapse before exporting can close the only automated route. Confirm with Honeycomb which API scopes and rate limits your plan includes and how long access continues after a downgrade notice.
Allow time for dual shipping
Send the same OpenTelemetry data to Honeycomb and the new backend in parallel so history builds up in the new system before you cut over. How long this takes depends on your traffic, the retention you need and the number of services you instrument, so model it against your own span volumes rather than a fixed period. Check that the parallel run ends before your Honeycomb access does.
Name owners for the Collector and backend
After cutover, someone must run the OpenTelemetry Collector pipelines, the ClickHouse storage, upgrades, backups and alert routing. Assign named owners for each component and agree who responds when telemetry stops flowing. Without this, the self-hosted stack can drift into an unmaintained state that is harder to operate than the hosted service it replaced.
Request written deletion confirmations
After exit, ask Honeycomb to confirm in writing when your customer data will be deleted, which systems and backups are covered, and whether any copies are retained for legal or billing reasons. Keep the confirmation with your exit records, since auditors and your own compliance team may ask for it. Also confirm how you will receive any final invoices and data export files.
Common questions about exporting data from Honeycomb
How much effort does exporting data from Honeycomb take?
The effort depends on how much you need to carry over, not on the export itself. The main drivers are the number of datasets, the length of history the business needs to keep, and the number of boards, triggers and SLOs that have to be recreated by hand in the new backend. Honeycomb's events expire after 60 days, so anything older than that must either be exported while you still have access or accepted as lost. Most of the work is rebuilding dashboards, alert logic and SLO definitions and validating that they produce the same answers. Ask any provider to inventory these items in writing before agreeing on scope.
How long should a dual-ship period run?
The dual-ship period should last long enough for the new backend to hold the history and alerting coverage your team relies on, and that is set by your own retention needs and review cycles, not by a fixed number. Because OpenTelemetry exporters can send the same telemetry to Honeycomb and a self-hosted backend in parallel, history builds up in the new system while the old one stays live. Factors that lengthen the period include incident review habits, quarterly reporting that compares trends, and services that deploy infrequently. Confirm the exit criteria with your engineering and operations leads before cutover starts.
What does the work need from our internal team?
You will need named owners for the services being instrumented, someone who can change exporter configuration in each deployment pipeline, and a person who knows which Honeycomb boards, triggers and SLOs are business critical. Security and platform teams are needed to approve where the self-hosted stack runs, how it authenticates and who can read the data. Expect a steady stream of decisions about which telemetry to keep, which to drop and how long to retain it. Without these people available during the overlap, the dual-ship period tends to drift.
Can an internal team run the export and migration alone?
An internal team can do it alone if it has engineers who know both OpenTelemetry configuration and the target backend, and if it has time to validate queries against the old data. Teams that lack operational experience with a column-oriented store, or that have many services to repoint, often bring in outside help for the design and cutover while keeping day-to-day ownership in-house. A fixed-scope written agreement makes the boundary clear: what is inventoried, what is rebuilt, what is tested and who signs off. Ask the provider which parts they will hand over and which you must retain.
Is the Honeycomb Query Data API required to leave?
No. The Query Data API is available on Honeycomb's Enterprise plan, so it is not something every customer has. Exporting does not depend on it if you can instead rebuild key queries and dashboards in the new backend and keep the OpenTelemetry pipeline sending data in parallel. If you do have access, the question becomes which results are worth extracting as records for audit or incident review, since raw events age out after 60 days. Confirm your plan's entitlements with Honeycomb before assuming any export path is available.
What happens to alerts during the cutover?
Alerts need the same care as data. Triggers and SLO burn alerts in Honeycomb do not move automatically, so each one must be recreated in the new backend and compared against the old definition. A common safe pattern is to run both alert sets during the dual-ship period, route the new ones to a test channel, and switch notification routing only after the team has seen them fire correctly. Check escalation paths and on-call integrations separately, because a missed page during cutover is the risk that matters most. Document each alert's owner and its disposition before the old one is disabled.
What should we ask a provider before agreeing to scope?
Ask for a written inventory method covering datasets, boards, triggers, SLOs and retention requirements, along with the acceptance tests that show the new backend returns comparable results. Ask who runs the dual-ship period, how exporters are changed and rolled back, and how alert routing is switched. Ask which deliverables are documented, which are handed over for your team to operate, and what ongoing support or retainer options exist after cutover. DeployOpen works from a written scope and does not publish a price list, so the quote follows from the answers to these questions.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Honeycomb exit, we start by mapping what you need to keep, then run the new backend beside Honeycomb so history builds up before you cut over.
How we scope
- Inventory the OpenTelemetry pipelines, datasets, boards, triggers and SLOs that need to move or be rebuilt
- Agree in writing which Honeycomb data you will export, archive or let expire, and over what window
- Confirm where the self-hosted backend will run and who owns storage, retention and access controls
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Configure the OpenTelemetry Collector to send the same OTLP telemetry to Honeycomb and the new backend in parallel
- Deploy SigNoz or the Grafana stack in your environment, with ClickHouse or other storage sized to your measured span volume
- Recreate dashboards, alert rules and SLOs in the new platform and check each against the Honeycomb original
- Harden authentication, transport encryption and network paths, and test the pipeline under realistic failure conditions
How we hand over
- Document the architecture, exporter configuration, retention settings and backup procedures for your operations team
- Provide a cutover runbook listing the order of exporter changes, validation steps and rollback points
- Record a decommissioning checklist for Honeycomb keys, datasets and integrations once you confirm the exit
- Deliver evidence of configuration and controls that your internal or external auditors can review
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover platform upgrades, backup verification and changes to retention as your span volume grows
- Ask for a named support scope, response expectations and upgrade responsibilities in the written quote
- DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications
