Skip to main content

Migrating an Existing Prometheus Setup to ClusterNest Managed Prometheus

Moving from a self-hosted Prometheus or VictoriaMetrics deployment is a remote_write endpoint and credential swap - nothing ClusterNest-specific about the migration mechanics themselves.

1. Create the cluster first​

Create a ClusterNest Managed Prometheus cluster sized for your existing workload's series count and set its retention_period to at least match what you currently keep, so historical queries (for however long you dual-write) don't come up short on one side.

2. Dual-write​

Add a second remote_write block to your existing Prometheus/agent config, pointing at the new cluster with the write credential, alongside the existing target you're migrating away from:

remote_write:
  - url: http://existing-target:9090/api/v1/write  # unchanged, your current setup
  - url: https://$PROMETHEUS_HOST/api/v1/push       # new: ClusterNest
    basic_auth:
      username: write
      password: $WRITE_PASSWORD

Both targets now receive every sample going forward - nothing about the source Prometheus's own scrape config needs to change.

3. Verify parity​

Once both targets have collected the same window of live data, compare a handful of queries against each - the same PromQL, one API vs. the other - and confirm dashboards render the same on both before relying on the new cluster alone. ClusterNest's query API is under /prometheus (see Querying + Grafana); the existing target's is whatever it already was.

4. Cut over​

Once parity is confirmed for however long you need (long enough to cover your retention/alerting window), remove the old remote_write block and point every consumer (Grafana datasources, alerting rules - see Alert rules & Alertmanager) at the ClusterNest endpoint exclusively. There's no historical-data import path - only what was dual-written during the overlap window is present on the new cluster, so keep the old system around (read-only) until nothing needs data further back than that.