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
    # optional: remote write 2.0, much less egress (see Pushing metrics in)
    protobuf_message: io.prometheus.write.v2.Request

The setting is per remote_write entry, so your existing target keeps receiving 1.0.

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.