From Grafana and Datadog to Elastic: PromQL in 9.5

Moving monitoring from one tool to another rarely fails on the technique of collecting data. Rebuilding the dashboards and alert rules that a team has built up over years usually takes the most time. The Elastic 9.5 release of 4 August 2026 touches both areas: native PromQL has reached GA, and Elastic describes a tool for moving dashboards and alerts from Grafana and Datadog to Kibana. Below we write about what this really changes in a migration, and where manual work is still needed.

What in 9.5 concerns migration

Feature	Status according to Elastic
Native Prometheus remote write and PromQL in ES|QL	GA in Elastic Stack from 9.5 (preview in 9.4)
Tool for migrating dashboards and alerts from Grafana and Datadog	GA according to the 9.5 announcement
Kubernetes integration (dashboards, alerts, SLOs, ML jobs)	GA
AWS integration	Technical preview
Columnar mode (columnar indexing)	Technical preview

Sources: the Elastic 9.5 announcement and the PromQL documentation. The documentation confirms the PromQL status: GA in Elastic Stack from 9.5 and in Serverless, preview in 9.4.

PromQL: existing Grafana queries without rewriting

The biggest benefit for teams with Grafana is that many of their queries written in PromQL can run on data in Elasticsearch, without being rewritten in another query language. Queries run through a Prometheus-compatible API (the /_prometheus/ prefix) or through the PROMQL command in ES|QL. Elasticsearch translates PromQL into an ES|QL plan and runs it with the same engine as the TS command. The metrics must be in time series data streams (TSDS), and the data can come from remote write, OTLP or the bulk interface.

Writing from an existing Prometheus is a short configuration:

remote_write:
  - url: "https://<elasticsearch-address>/_prometheus/api/v1/write"
    authorization:
      type: ApiKey
      credentials: "<api-key>"

By default data goes to the metrics-generic.prometheus-default stream, and the API key must have write access to it. Compatibility with Prometheus is not complete. Elastic keeps a separate page listing supported and unsupported functions and differences in behaviour, and you should rely on it when assessing whether your queries will pass unchanged.

The migration tool: how far to trust it

In the 9.5 announcement the tool for moving dashboards and alerts from Grafana and Datadog has GA status. Some caution is in order here, because other Elastic sources describe it more carefully. Elastic’s post of 28 April 2026 calls it the Observability Migration Platform (obs-migrate) and says the tool is “still evolving”: coverage is broader for Grafana and narrower for Datadog. The Datadog migration documentation, at the time of writing, still describes rebuilding dashboards and monitors by hand. It is sensible, then, to treat the tool as a way to speed up the work, not as a “migrate” button.

The description in the April post shows how the tool works:

• it reads dashboards and alerts from export files or from the Grafana and Datadog APIs,
• it translates queries and panels into Kibana objects, and when a translation is not safe, it marks the panel for manual correction or replaces it with a safe placeholder,
• the result can be validated against the cluster and uploaded to Kibana,
• imported alert rules are disabled by default until you review them,
• after a run you get reports (migration_report.json, verification_packets.json, run_summary.json) showing what passed cleanly and what needs attention.

An example call from that post for Grafana from files looks like this:

obs-migrate migrate \
  --source grafana \
  --input-mode files \
  --input-dir ./grafana_exports \
  --output-dir ./migration_output \
  --assets all \
  --native-promql \
  --data-view "metrics-*" \
  --validate \
  --upload

The original also has the Elasticsearch and Kibana addresses and keys. Note that the post describes a run against an Elastic Observability Serverless project, so for a cluster on your own infrastructure, check in the documentation whether it is a supported path.

How we plan such a migration

In a move like this, the order and a period of parallel running decide the outcome, not the choice of tool. We recommend this order:

1. Inventory. A list of the dashboards and alerts that someone actually uses. Often some of them have not been opened for a long time and need not be moved.
2. Parallel writing. Data goes to the old and the new system at the same time. For Prometheus that is a second remote_write entry, for OpenTelemetry a second exporter in the collector. We described sending data over OTLP in the article on Elastic 9.4 for metrics.
3. Migration and review of dashboards. The tool does the heavy part, and a person checks every important panel against the old chart.
4. Alerts. Enable them one at a time and compare them with what the old system reported, for at least a few weeks.
5. Switching off the old system only after a period without discrepancies.

Integrations and onboarding in 9.5

Besides migration, 9.5 also simplifies connecting sources. The Kubernetes integration has GA status and ships with dashboards, alerts, SLOs and machine learning jobs. The announcement also describes simplified Kubernetes and AWS onboarding, which uses the OpenTelemetry path by default, and managed integrations that pull cloud data without agents on the customer’s premises. For companies moving their monitoring this means less manual configuration, but you still need to check that metrics from the new source have the same names and labels that the migrated dashboards refer to.

Changes from 9.5 to know about when upgrading

The release notes for 9.5 list, among other things, a change to the look-ahead time in time series data streams: from 30 to 9 minutes. Documents with a timestamp more than 9 minutes in the future will be rejected. If your agents or devices have inaccurate clocks, check this before upgrading. You restore the previous value with the index.look_ahead_time setting in your templates. Before upgrading, also review the full list of breaking changes.

When it makes sense

Moving to Elastic pays off most when you want logs, metrics and traces in one place and your team already knows PromQL. If Grafana and Prometheus work well and nobody complains about costs, there is no reason to touch them. We move monitoring from Grafana, Datadog and Splunk to Elastic as part of monitoring migration.