Migrate Datadog logs to Grafana Loki

How to migrate Datadog logs to Grafana Loki without losing history

A platform team pays a growing Datadog log bill, or its compliance office has decided that log data must stay in the company's own storage. The move is mainly three pieces of work: rerouting log shippers so new events reach Loki, keeping archived history in your own object storage, and rebuilding log-based alerts and saved views in Grafana. Platform or SRE engineers usually own this work, often with an implementation partner who handles the Loki deployment, storage wiring and cutover checks. The effort is driven less by the Loki install itself than by how many log sources, pipelines and alerts you have, so ask for an inventory before you agree on scope.

Start with the shippers. Datadog Agents, which are open source in their user space components under Apache-2.0, can be replaced by Grafana Alloy, Grafana's supported shipper for Loki, or by a standard OpenTelemetry Collector pipeline. Loki also accepts Fluent Bit, Fluentd and OpenTelemetry logs over HTTP. Run old and new shippers side by side for a period, then compare event counts per source. For history, Datadog Log Archives can write compressed JSON to your own S3, Azure or GCS bucket, and that archive is not the same as a live Loki index. Confirm the archive format and whether you can replay it into Loki before you stop the Datadog pipelines. Set retention_enabled in the Loki compactor deliberately, because retention is off by default and logs are then kept indefinitely, which is also a storage cost you will now pay.

Which Datadog log features map to Loki, and which need rework

This table compares the main Datadog log features with their Loki equivalents, marking each as clean, needs rework or gap. Read it as a checklist for what moves over with little change, what must be rebuilt, and what has no direct replacement and needs a compensating control. The main takeaway is that ingestion and storage map cleanly, while pipelines, saved views, RBAC and log-based alerting need deliberate rework.

Datadog feature	Loki with Grafana Alloy and Grafana	Status
Log ingestion from agents	Grafana Alloy or OpenTelemetry Collector ships logs over OTLP or native log pipelines to Loki, and Fluent Bit or Fluentd also work	Clean
Log Archives to your bucket	Keep archived JSON in your S3, Azure or GCS bucket for history, and load it into Loki only if you need it searchable again	Needs rework
Pipelines and parsing	Parsing moves into Alloy processing stages or OpenTelemetry processors, so each Datadog pipeline rule must be rewritten and tested	Needs rework
Log-based metrics and monitors	Use LogQL metric queries in Grafana alert rules, then route notifications through your existing alerting tool	Needs rework
Saved views and facets	Grafana Explore queries and saved dashboards replace saved views, but facet-style filtering must be rebuilt from labels	Needs rework
Retention and storage	The compactor enforces retention only when retention_enabled is set, so you must size object storage and set rules per tenant or stream	Needs rework
Role-based access control	Loki has no built-in authentication layer, so place an authenticating reverse proxy such as OAuth2 Proxy or Pomerium in front of it, and use Grafana roles for dashboard access	Gap
Tenant separation	Loki uses the X-Scope-OrgID header when auth_enabled is true, which the reverse proxy must set from verified identity	Needs rework
Log search in the UI	Grafana Explore with LogQL covers search and live tail, but confirm query performance on your own data volumes	Clean

What data leaves Datadog and what must be rebuilt

Log history and log configuration leave Datadog by different routes. Archived log files can be moved into storage you control, but the saved views, pipelines, monitors, dashboards and log sources that make those logs usable have to be rebuilt in Grafana and Loki. Treat each group below as a separate workstream with its own owner and acceptance check.

Log Archives as the history path

Datadog Log Archives can write logs as compressed JSON to an S3, Azure or GCS bucket that you own. This is the documented route for keeping history after you stop paying for Datadog ingestion. Archived files are not directly queryable in Loki, so decide early whether history will be replayed into Loki, queried with another tool, or kept only for retention and audit. Confirm the archive format, bucket permissions and the retention you need with your Datadog administrator.

Archive bucket access and lifecycle

The archive bucket becomes a long-lived store of log data, so its access model matters as much as its contents. Restrict write access to the Datadog archive role and read access to a small operations group, and set object lifecycle rules that match your legal hold and retention policy. Loki retention applies only to data Loki holds, so bucket lifecycle rules are a separate control you must set and document.

Saved views and pipelines

Datadog saved views, facets and log processing pipelines define how raw logs are parsed, enriched and filtered. None of these move automatically. In Loki, parsing happens in the shipper (for example Grafana Alloy) or in LogQL at query time, so each pipeline stage must be rewritten as configuration you keep in version control, and each saved view becomes a LogQL query or a Grafana Explore bookmark.

Log monitors and alert rules

Datadog log monitors evaluate log queries against thresholds and send notifications through Datadog integrations. Each monitor must be rewritten as a Grafana alert rule that uses a LogQL metric query, with its own threshold, evaluation window and contact point. Compare alert behavior during a parallel run, since a rule that is silent in Grafana can look like a healthy service, and document which routing and on-call tool receives each alert.

Dashboards and log sources

Dashboard JSON can be exported from Datadog through its API as a reference, but panels that query Datadog log indexes must be rebuilt against Loki data sources. Log sources such as cloud audit logs, Kubernetes container logs and load balancer logs are configured in Datadog integrations and must be re-pointed at Alloy, Fluent Bit or other shippers. Inventory every source before cutover so none goes silent.

Rebuilt definitions as code

Keep the rebuilt configuration in Git rather than in the Grafana UI alone. Grafana provisioning loads data sources, dashboards and alerting resources from YAML or JSON files at startup, and Grafana documents Terraform and Git Sync as further as-code options. Store data source definitions, alert rules and dashboards in the same repository as your shipper configuration, so reviews, rollbacks and audit evidence come from one source of truth.

Migration sequence from inventory to Datadog decommission

This sequence moves Datadog log management to Grafana Loki in controlled stages, so every log source is accounted for, parsing and alerts are proven against Datadog before cutover, and Datadog history is preserved in your own object storage before the subscription ends.

Inventory log sources and volumes
Platform and application owners list every log source that reaches Datadog today, including hosts running the Datadog Agent, containers, serverless functions, cloud services and any OpenTelemetry pipelines. For each source, record the shipper, the Datadog index or pipeline it feeds, approximate daily volume from Datadog usage reporting, and the teams that depend on it. Output: a source inventory with owners and volumes, reviewed by the security and compliance leads who must sign off on what history must be retained. The step is done when every source is either assigned to a migration wave or marked for retirement.
Choose the Loki deployment mode and size the pilot
Using the inventory, the platform team selects a Loki deployment mode. Loki documents monolithic mode for small volumes, simple scalable mode for larger ones, and microservices for very large clusters, and notes that simple scalable mode is being deprecated, so confirm the current guidance before choosing it. Confirm with Grafana which object store you will use for chunks and index, since Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production options. Output: a written architecture decision and a pilot environment in your own cloud account or data center.
Stand up a pilot tenant with access controls
The platform team deploys Loki, Grafana and the shipper for the pilot, enabling multi-tenancy with auth_enabled if more than one team will query logs. Loki has no built-in authentication, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must sit in front of it. Grafana should run with a production database (MySQL or PostgreSQL), not SQLite. Output: a validated pilot tenant that accepts logs from two or three representative sources, with access restricted to the pilot group and tested for unauthenticated request rejection.
Dual-ship logs to Datadog and Loki
For each pilot source, the shipper sends the same log lines to Datadog and to Loki in parallel. Grafana Alloy, a distribution of the OpenTelemetry Collector, is Grafana's supported shipper for Loki, and Loki also accepts Fluent Bit, Fluentd and OpenTelemetry logs over HTTP. Keep the Datadog path unchanged so that Datadog remains the reference during validation. Output: a dual-shipping configuration per source, with a record of which source was switched and when, and a check that log counts for the same window broadly match in both systems.
Validate parsing, labels and alert parity
Compare the same events in Datadog and Loki. Verify that timestamps, multi-line handling, severity fields and key attributes survive the pipeline, and that LogQL queries return the results your saved Datadog views produced. Rebuild each log-based monitor as a Grafana alert rule and run both alert paths against known events, confirming that the same conditions fire and that notification routing is correct. Note that Grafana alerting in high availability needs extra configuration to avoid duplicate notifications. Output: a signed parity checklist listing each saved view, monitor and pipeline with its status and the owner who accepted it.
Cut over shippers and set retention
Once parity is signed off, the platform team removes the Datadog destination from each shipper in waves, starting with the least critical sources. Retention is then configured in Loki, which is disabled by default and keeps logs indefinitely until retention_enabled is set, so set global or per-stream retention deliberately. Each stream rule must be at least 24 hours. Output: a retention policy approved by compliance and data owners, and a cutover log showing each source moved to Loki only.
Archive Datadog history to your own storage
Before Datadog log retention lapses, configure Datadog Log Archives to write compressed log data to a bucket you control, such as an S3, Azure or GCS bucket, and confirm the archive is complete and readable. Historical logs can be reloaded into Loki if needed, but that is a separate job with its own parsing checks. Ask Datadog and your compliance lead which retention periods apply to archived data and whether the archive satisfies your records obligations. Output: a verified archive location with access controls, a listing of archive contents, and a written record of the retention rule applied to it.
Decommission Datadog log products
After a stable period in which no source depends on Datadog for logs, the team removes log indexes, pipelines, archives that are no longer needed and API keys with log scope, and confirms with Datadog how billing changes at the end of the subscription. Review access logs for the Datadog account, revoke remaining integrations, and update runbooks and on-call documentation to point at Grafana. Output: a decommission record signed by the service owner, showing that no shipper, alert or dashboard still references Datadog log endpoints.

Running Datadog and Loki in parallel before cutover

Dual shipping is possible because the log path is a fan-out point, not a one-way pipe. The Datadog Agent or an OpenTelemetry Collector pipeline can export the same log stream to Datadog and to Loki at the same time, so you do not have to choose between the two during the overlap. In practice, the cleanest new shipper is Grafana Alloy, Grafana's vendor-neutral distribution of the OpenTelemetry Collector and its supported log shipper for Loki. Deploy Alloy alongside the existing shipper, point one copy of each log source at Loki, and leave the Datadog path untouched until you have evidence that Loki is complete. Confirm with your Alloy version and component configuration that your log parsing, labels and multiline handling match what Datadog currently receives, because a mismatch here shows up later as a comparison failure rather than an error.

Compare the two backends on three things over the overlap window. First, volume: compare bytes and line counts per source and service in Datadog against what Loki stores, accounting for compression and for any fields you drop or redact on one side only. Second, query results: pick a set of saved searches and incident investigations, run the equivalent LogQL and Datadog queries, and check that counts and sample lines agree for the same time ranges. Third, alert firing: run each log-based alert in shadow mode or against the same window, and record whether Datadog and the rebuilt Loki rule fire on the same events. Keep Loki's auth_enabled setting and tenant handling in mind here. When auth_enabled is true, Loki identifies each tenant by the X-Scope-OrgID header on every request, so each team's shipper and query path must send the correct value. Loki has no built-in authentication layer, so the reverse proxy in front of it must also enforce which teams can read which tenant. Test that a team cannot query another team's tenant before any shared cluster goes live.

Stop Datadog ingestion for a source only after its volume, query and alert checks pass and its owners sign off. Stopping ingestion does not end your history: Datadog Log Archives can keep writing to your own object storage, so older logs remain available outside Datadog after the live stream is removed. Confirm that the archive configuration continues to run after ingestion stops, that the bucket and its access controls are correct, and that your retention rules in Loki and in the archive store match the obligations you have. Treat Loki retention as a cost you now own: the compactor applies retention only when retention_enabled is set, and logs are kept indefinitely otherwise. Set retention deliberately per tenant or stream before you cut over, and confirm the figures with your storage team, since the object storage bill recurs and grows with the period you keep.

Choosing a Loki deployment mode for your log volume

Monolithic mode runs Loki as a single binary that handles reads, writes and compaction together. Loki's deployment modes documentation places it at small volumes, up to about 20 GB of logs per day. It is the simplest option to install, upgrade and back up, and it suits a pilot that replaces Datadog log shipping for one team or one environment.

Operational footprint: One process and one set of configuration keys to manage, which keeps the on-call surface small.
Storage: Chunks and the index still go to object storage, so the local disk holds only working data.
Growth limit: Plan a move to another mode before daily volume approaches the documented ceiling, not after queries slow down.
Replication: Confirm how you will handle restarts and upgrades on a single process, since there is no separate read path to fail over.
Cost driver: Most recurring spend is object storage and the compute that runs the binary, both of which you can size from your own ingest measurements.

Before you commit, confirm the current volume guidance in the Loki deployment modes documentation against the release you plan to deploy.

What usually goes wrong with a Datadog to Loki log migration

Most failed log migrations do not fail at ingestion. They fail later, when storage grows without limit, endpoints are reachable by the wrong people, alerts silently stop firing, fields disappear, or the Grafana control plane cannot survive a restart. Each risk below has a concrete check you can run before cutover.

Retention left disabled

Loki keeps logs indefinitely until retention is switched on, so a fresh deployment carries no expiry at all. Because Datadog billed you for retention per GB, the storage bill now replaces that line item directly, and nobody may notice until object storage costs arrive. Set retention before the first production write: enable retention in the compactor, then choose global, per-tenant or per-stream rules that match the periods your compliance owners have agreed. Remember that each stream rule must be at least 24 hours.

Unauthenticated Loki endpoints

Loki has no built-in authentication layer. Datadog handled API keys and user access for you, but a Loki push or query endpoint reachable without a proxy exposes every log line to anyone who can reach it. Place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of Loki and restrict the network path to the shippers and Grafana. In multi-tenant setups, confirm that clients cannot set arbitrary X-Scope-OrgID values to read other tenants' streams.

Alerts on mismatched labels

Datadog log monitors query facets and attributes that your team has used for years. Loki selects streams by labels, and a rule written against a label that the new shipper does not attach will simply return no data, so the alert never fires. Compare the label set from your old and new pipelines for every migrated alert and run each rule against known-bad sample events during dual shipping. Treat a rule that has never produced a result as unverified.

Parsing differences drop fields

Datadog pipelines parse and enrich logs with processors that have no one-to-one equivalent in a Loki shipping path. Fields extracted at ingest in Datadog can be absent or stored as unparsed text in Loki, which breaks dashboards and searches that depend on them. Grafana Alloy is Grafana's supported shipper for Loki, so rebuild each parsing rule in the shipper configuration and compare sample events field by field before you retire the Datadog pipeline.

Grafana running on SQLite

Grafana stores dashboards, users and alerting state in SQLite by default. That default works for a trial, but the Grafana installation docs say SQLite does not scale for production, and high availability needs a shared MySQL or PostgreSQL database. Point Grafana at MySQL 8.0 or later, or PostgreSQL 12 or later, before any analyst depends on the saved views. Back up that database on the same schedule as the Loki object store, because a lost Grafana database means rebuilding every dashboard and alert by hand.

What drives the cost and duration of the move

This table lists the factors that change how much the move costs and how long it takes, with a reason and a way to reduce each one. Treat Datadog ingestion and indexing charges as one line, and the Loki storage, compute, Grafana and staff time as separate lines, so the two sides can be compared on equal terms. No prices are stated here, so ask for each figure in a written quote.

Driver	Why it changes cost or effort	How to keep it down
Daily log volume	Drives object storage growth, write capacity and the Loki deployment mode you need, since monolithic mode suits smaller volumes and larger volumes need simple scalable or microservices modes.	Filter debug and health-check noise at the shipper, and measure real daily volume from Datadog before sizing.
Number of sources and parsing rules	Each source needs a shipper configuration, labels and parsing logic in Grafana Alloy or another shipper, so effort grows with every distinct log format.	Group sources by format, reuse shared pipeline templates and retire sources nobody reads.
Saved views and log monitors	Each Datadog saved view and log monitor must be rebuilt as a LogQL query, Grafana dashboard panel or alert rule, and must be tested against the new labels.	Inventory views and monitors, delete unused ones and rebuild only those tied to an active on-call or compliance use.
Archive size and history needs	Log Archives in your own object storage hold compressed JSON history, which must be moved, indexed or kept for reference, and the storage bill runs in parallel with Loki.	Confirm which history must be queryable in Loki and which can stay as archived files, and ask for the archive size before choosing a load path.
Retention targets	Loki retention is disabled by default, so logs stay forever until you set it, and each retention rule adds storage that you now pay for directly.	Set retention per tenant or stream selector from documented requirements, with each rule at least 24 hours as the Loki retention docs require.
Grafana high availability	Production and high availability need MySQL or PostgreSQL for configuration, plus two or more active-active Grafana servers behind a load balancer, which adds database and compute cost.	Decide early whether a single node is acceptable for the user group, and confirm alerting configuration to avoid duplicate notifications in HA.
Identity integration	Loki has no built-in authentication, so an authenticating reverse proxy is required, and SAML, team sync and SCIM are limited to Grafana Enterprise or Grafana Cloud according to the Grafana authentication docs.	Reuse your existing OAuth or LDAP provider and confirm early whether SAML or SCIM is a requirement, since that changes the edition decision.
Number of teams and tenants	Each team that needs separate access may need its own tenant through X-Scope-OrgID and its own dashboards, folders and permissions, multiplying review and testing effort.	Start with a small set of teams, define a shared label scheme and add tenants only when access boundaries require them.

Questions teams ask before moving Datadog logs to Loki

How much effort does moving Datadog logs to Loki take?

The effort depends mostly on how many log sources you have, how many pipelines and parsing rules you rely on in Datadog, and how many saved views and log-based monitors depend on them. Each shipper (Datadog Agent, Fluent Bit, Fluentd, Docker logging driver or OpenTelemetry Collector) must be re-pointed, and Loki needs a label strategy that matches how your teams query logs. Parsing rules that live in Datadog pipelines must be re-created in Alloy or the shipper config. Ask a partner or your internal team to inventory sources, pipelines, saved views and monitors before estimating, since that inventory sets the scope. Any duration or fee should come from a written scope, not from this page.

Can our internal team migrate Datadog logs to Loki without a partner?

Often yes, if the team already runs Linux services, object storage and a log shipper, and has someone who can design Loki labels and retention. The work is mostly configuration and rebuilding queries, not new software. Teams without experience running stateful storage, authentication proxies or upgrades on a regular cadence usually need outside help for those parts. Grafana's upgrade guidance describes minor releases every other month and patch releases at least monthly, so someone must own that cycle. Check your skills against the work list before deciding.

How long does dual running usually last, and what sets that length?

Dual running length is set by how long you need to compare results before trusting Loki, not by a fixed rule. Teams usually keep Datadog receiving logs while the same records flow to Loki, then compare volumes, missing fields, query results and alert behavior. Length is driven by log volume, the number of teams that must sign off, the number of compliance-relevant log sources, and how many alerts must be rebuilt and tested. Your Datadog contract end date and any Log Archive requirements also affect the window. Set exit criteria in writing before cutover.

Can archived Datadog logs be queried in Loki?

Not directly. Datadog Log Archives write compressed JSON to your own S3, Azure or GCS bucket, and Loki does not read that format as its native store. To query history in Loki, you would need to write a loader that parses the archived files and pushes them to Loki, or keep the archives in object storage for retrieval when needed. Loki-native history only exists for data ingested after cutover. Confirm the archive file layout and the loader approach in a test before you plan retention, because the loader is the real work.

How does log retention affect storage cost in Loki?

In Loki, storage cost is driven by how much you ingest and how long you keep it, and both are stored in object storage that you pay for. Retention is disabled by default in Loki, so logs are kept indefinitely until you turn it on with the compactor. You can set retention globally, per tenant or per stream selector, and each stream rule must be at least 24 hours. Compare this to Datadog, where log storage and indexing are billed per GB or per event. Ask for a sizing estimate based on your measured daily volume, and set retention rules before go-live so storage does not grow without limit.

What does Loki need for authentication and multi-tenancy?

Loki has no built-in authentication layer, so you must place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Multi-tenancy is turned on with auth_enabled set to true, and each request must carry an X-Scope-OrgID header that identifies the tenant. Grafana's own authentication options, including LDAP, generic OAuth, Entra ID and Okta, cover user login to dashboards, but SAML and SCIM are available only in Grafana Enterprise and Grafana Cloud. Confirm which identity provider and access model your security team requires before designing the proxy layer.

Which Datadog log features need extra work in Loki?

Expect extra work for pipelines that enrich, parse or redact logs inside Datadog, for saved views and facets, and for log-based monitors. Loki queries use LogQL and label selection, so facets and saved views must be rebuilt as dashboards or queries. Sensitive field masking must be re-implemented in the shipper or Alloy pipeline before logs leave your hosts. Test each rebuilt monitor against replayed logs before you disable the Datadog version, and record which alerts changed behavior.

How DeployOpen scopes and runs a Datadog log migration

DeployOpen plans and implements the move of Datadog log management onto a self-hosted Grafana Loki stack inside your own infrastructure. We start from a written scope that names the log sources, the Log Archives history, the alerts and saved views to rebuild, and the retention you want to keep.

How we scope

Inventory every log source sending to Datadog, including agents, forwarders and any OpenTelemetry Collectors, and record where each one ships.
Confirm which Datadog log indexes, pipelines, saved views and log-based monitors are in use, and which are still needed.
Agree in writing the retention periods per stream, the object storage target and the history to load from Log Archives, with engagements fixed-scope.

How we build

Deploy Loki in the deployment mode that matches your daily log volume, with object storage configured for chunks and the index.
Re-point log shippers, using Grafana Alloy or OpenTelemetry Collector pipelines, and run them in parallel with Datadog during cutover.
Rebuild log-based alerts and saved views in Grafana, enable authentication through a reverse proxy in front of Loki, and test each one against real traffic.

How we hand over

Document the architecture, tenant and header configuration, retention rules, and the mapping from each Datadog monitor to its replacement.
Provide runbooks for compactor retention, storage growth checks, and the steps to add a new log source to the pipeline.
Walk your operations and security staff through access controls, backups of the object store, and the evidence needed for internal reviews.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, covering Loki and Grafana release updates.
Ask for a retainer scope that names which upgrade, patching and monitoring tasks are included and how incidents are escalated.
Ask us to confirm in the written scope which parts of the stack are covered after handover and who owns each one.