Inventory
Record ingestion endpoints, labels, resource attributes, dashboards, API clients, retention expectations and the queries used during incidents
Controlled migration paths
Migrate to PulsusDB
Keep familiar query languages
Migrate metrics from Prometheus®, logs from Grafana Loki and traces from Grafana Tempo by running PulsusDB beside the current backend. Dual-write telemetry, compare representative queries and change datasource endpoints when the results and operational behaviour are understood
migration.planVALIDATE BEFORE CUTOVER
TELEMETRY PIPELINE Collect once OpenTelemetry · remote write
CURRENTExisting backendremains available
NEWPulsusDBparallel ingest
COMPARE QUERIES · DASHBOARDS · DATA
PromQLLogQLTraceQLExisting clients
rollback path stays opencut over by signal or team
A staged change
Move the data path
Without a flag day
A migration does not need to replace every backend, dashboard and collection route at once. Keep the current system available while PulsusDB receives the same telemetry, then move one signal, environment or team at a time
Dual-write
Add PulsusDB as another destination in the existing OpenTelemetry or metrics pipeline without removing the current backend
Compare
Run representative PromQL, LogQL and TraceQL queries against both systems and investigate differences before users move
Cut over
Change datasource and client endpoints in controlled groups while keeping the original backend available for rollback and older data
Migration by signal
Start from the backend
You run today
Each signal has a different collection path, but the migration shape is the same: write to both backends, validate the familiar query interface, then move clients to PulsusDB
METRICS01
Prometheus to PulsusDB
Keep PromQL and Prometheus-compatible clients while moving long-term metric storage and analytical execution to PulsusDB
- ROUTE
Use remote write or OpenTelemetry metrics to send the same samples to PulsusDB and the current metrics backend
- VALIDATE
Compare series discovery, label values, range functions, vector matching and dashboard time ranges
- SWITCH
Point Prometheus-compatible datasources and API clients at PulsusDB after the selected queries agree
LOGS02
Grafana Loki to PulsusDB
Keep LogQL selectors and pipelines while storing logs in a ClickHouse® database model built for selective scans and efficient retention
- ROUTE
Add an OTLP/HTTP destination to the existing log collection pipeline and preserve stream identity as resource attributes
- VALIDATE
Compare stream labels, structured parsing, whole-word filters, pipeline stages, aggregations and time boundaries
- SWITCH
Change the Loki-compatible datasource endpoint for a selected team or environment before broadening the cutover
TRACES03
Grafana Tempo to PulsusDB
Keep TraceQL search and trace exploration while moving spans to PulsusDB through the OpenTelemetry pipeline already serving applications
- ROUTE
Add the PulsusDB OTLP endpoint to the trace exporter or collector while Tempo continues receiving the same spans
- VALIDATE
Compare trace ID lookup, tag discovery, attribute filters, duration predicates and structural TraceQL queries
- SWITCH
Move Tempo-compatible datasource traffic to PulsusDB after trace completeness and query results are verified
MULTI-SIGNAL04
OpenTelemetry pipelines
When telemetry already passes through an OpenTelemetry Collector, migration begins by adding another exporter rather than replacing instrumentation
- ROUTE
Add a PulsusDB OTLP/HTTP exporter to the required logs, metrics and traces pipelines
- VALIDATE
Confirm batching, retries, resource attributes, timestamps and signal volume before changing downstream clients
- SWITCH
Make PulsusDB the primary destination one pipeline at a time and keep the previous exporter during the rollback window
What changes and what remains
Change endpoints
Preserve query workflows
PulsusDB exposes familiar observability interfaces over a different storage and execution model. Migration validation should cover the exact functions, pipeline stages and client behaviour your teams depend on
Current systemParallel ingestQuery interfaceCutover change
PrometheusRemote write or OTLP metricsPromQL and Prometheus HTTP APIDatasource or API endpoint
Grafana LokiOTLP logsLogQL and Loki-compatible APIDatasource endpoint
Grafana TempoOTLP tracesTraceQL and Tempo-compatible APIDatasource endpoint
OpenTelemetry backendAdditional OTLP exporterPulsusDB query APIsExporter and client endpoints
Production cutover runbook
Prove the path
Then move traffic
Use production-shaped telemetry and real operational queries. Synthetic checks are useful, but they rarely expose differences in label cardinality, late samples, sparse traces or pipelines built around unusual log formats
Open the PulsusDB docs ↗Define acceptance queries
Choose dashboards, API calls and incident queries that represent normal and difficult workloads
Measure ingestion parity
Compare sample, log and span counts by service and time window while watching rejected or retried batches
Validate query semantics
Check results, timestamps, empty series, label sets, ordering and edge cases rather than comparing only response status
Move a bounded audience
Cut over a development environment, service group or dashboard folder before production-wide client changes
Keep rollback simple
Leave the original write path and datasource configuration available until the agreed observation window is complete
HISTORICAL DATA
Begin with forward writes
Build confidence with new telemetry before treating backfill as part of the critical path. Keep the previous backend available for older time ranges during the overlap period. If historical import is required, validate the source export format, label and attribute mapping, timestamp precision and current PulsusDB import support before loading production data
Check current import documentation ↗PLAN THE FIRST CUTOVERStart with one signal
Start with one signal
And the queries that matter
Choose the current backend, establish a parallel ingest path and validate the real dashboards and investigations your team already uses