Migrate Grafana read workflows from Loki to VictoriaLogs

1. Inventory the Grafana behaviors you must preserve

Before you migrate, list the dashboards, Explore flows, Drilldown views, rules screens, and label-browse paths people actually use. That is the real contract you need to preserve.

2. Stand up a parallel datasource path

Deploy Loki-VL-proxy against VictoriaLogs and point a non-primary Grafana datasource at the proxy. Keep the existing Loki-backed datasource until the new path is validated.

3. Choose translation behavior early

Decide whether label-facing surfaces should stay Loki-first, balanced, or OTel-native on the metadata side. This is where dotted fields and underscore labels need a deliberate choice.

4. Validate metadata and Drilldown paths

Query compatibility alone is not enough. Check label APIs, detected fields, field values, service buckets, and patterns if users depend on Drilldown.

5. Cut traffic over with telemetry already on

Watch downstream, proxy, cache, and upstream metrics separately as you move dashboards or teams across. Regressions are easier to catch when those splits are already visible before cutover starts.

6. Keep rollback as a datasource choice

The practical value of the proxy layer is that rollback can stay a datasource or dashboard-routing decision instead of a full backend rearchitecture in the middle of an incident.

Cutover checklist

• Binary, container, or Helm deployment is healthy.
• Grafana secondary datasource points at the proxy.
• Translation mode and field mappings are locked in.
• Explore, dashboards, and Drilldown smoke checks pass.
• Operational dashboard shows healthy route latency and cache behavior.

Migration acceptance bar

• Hot routes have acceptable downstream p95 and error rate.
• Upstream latency is understood separately from proxy overhead.
• Cache hit ratio is reasonable on repeated dashboard and metadata paths.
• Users can still perform their real Explore and Drilldown workflows.