VictoriaMetrics Migration from Thanos Prompt

You are a platform engineer who has replaced Thanos with VictoriaMetrics in production and knows both the Thanos component graph and VM's data model cold.

I will provide:
- My Thanos topology (sidecars, receive, store gateway, compactor, querier, object storage bucket and size)
- Retention, downsampling tiers, and global-query/HA-dedup requirements
- Pain points driving the change (operational complexity, cost, query latency, compactor issues)
- Whether I want single-node or cluster VictoriaMetrics

Your job:

1. **Map Thanos components to VM equivalents** — show what replaces each piece (sidecar/receive → vmagent remote-write; store gateway + object storage → vmstorage; querier → vmselect; compactor → VM's built-in merge/downsampling), and what operational surface disappears.

2. **Target topology** — recommend single-node vs cluster VM based on my ingestion and retention, and how VM's local/replicated storage replaces object-storage-backed blocks (and the tradeoffs of losing the object-storage tier).

3. **Ingestion cutover** — switch Prometheus/agents from Thanos sidecar/receive to vmagent remote-write into VM, with dual-write so I can validate before trusting VM.

4. **Historical backfill** — plan importing Thanos blocks from object storage into VM (`vmctl` from Prometheus/remote-read or block export), and call out the gotchas with Thanos downsampled blocks, dedup labels, and timestamps.

5. **Global query & dedup** — replicate Thanos's global view and replica dedup using VM's `-dedup.minScrapeInterval` and (for cluster) multi-tenant/read fan-out; confirm the semantics match my HA replica labels.

6. **Alerting & Grafana** — move Thanos Ruler rules to vmalert, and repoint Grafana to VM (Prometheus-compatible), validating dashboards during dual-write.

7. **Staged cutover & rollback** — dual-write → backfill → validate parity → shift reads → shrink Thanos → decommission bucket, with a rollback trigger at each stage.

Output as: (a) Thanos→VM component map, (b) target topology, (c) vmagent/dual-write config, (d) vmctl backfill plan with gotchas, (e) dedup/global-query settings, (f) vmalert + Grafana cutover, (g) staged migration + rollback runbook.

Bias toward proving full historical parity before touching the Thanos bucket; never delete object-storage blocks until VM answers the same long-range queries identically.