Overview
A Loki migration moves log collection from an existing system, usually an Elasticsearch-based stack or a hosted logging tool, onto Grafana Loki running in infrastructure you control. Loki indexes only labels and stores compressed log chunks and their index in object storage, so the work is less about mapping every field and more about deciding which labels matter, how shippers attach them, and how existing search habits translate into LogQL queries and Grafana dashboards. Teams also tend to plan for the Loki-driven changes that arrive during the move: Promtail reached end of life on March 2, 2026, and Grafana directs users to Grafana Alloy; older index stores such as DynamoDB, Bigtable and Cassandra are deprecated in favor of TSDB; and simple scalable deployment mode is being deprecated and will be removed with Loki 4.0. Confirm the exact versions and dates that apply to your target release before you set the plan.
Common triggers include licensing or cost pressure on the current platform, hosted ingestion pricing that grows with volume, data residency requirements that keep logs inside a specific jurisdiction or network, and a decision to consolidate on Grafana for metrics, traces and logs. Many teams run the cutover in-house, with their own platform engineers moving shippers and dashboards, and bring in a partner for specific pieces such as query translation, shipper rollout across hosts, or the index migration. Decide early which of those pieces you will own and which you will hand over.
What the work includes
The migration runs as six workstreams that overlap in time, with deliverables that let your operators run and change the Loki stack after the project closes. Scope and sequencing are agreed in writing before work starts.
Source inventory and volume profiling
We list every log source, shipper, index, dashboard and alert that depends on the current stack, then profile daily ingest by source and by label set. The profile decides the deployment mode, object storage sizing and which sources need cleanup before they move. Ask who owns each source and whether any feed carries regulated or sensitive fields.
Label and tenant design
Loki indexes labels, not full text, so label choices control both query speed and cardinality. We design a small, stable label set, map each business unit or environment to a tenant identified by X-Scope-OrgID, and document which labels are banned because they are high cardinality. Confirm early whether auth_enabled will be on from day one.
Shipper migration to Grafana Alloy
Promtail reached end of life on March 2, 2026, so existing Promtail agents move to Grafana Alloy. Where Fluent Bit, Fluentd or OpenTelemetry Collector pipelines already run, we keep them if they meet requirements and document the output configuration. Each host group is migrated in batches with rollback steps, and the labels it emits are checked against the catalog.
Query and dashboard translation to LogQL
Searches, saved queries and dashboards written in the source query language are translated into LogQL, then checked against the same time windows and expected results. Some constructs have no direct equivalent, so we flag them for redesign rather than forcing a literal copy. Ask which dashboards are used weekly and which can be retired.
Alert rule migration
Each alert is rebuilt as a Loki or Grafana alert rule, with its threshold, evaluation window, routing and notification target confirmed against the original. We test each rule with replayed or synthetic events so teams see that it fires when it should. Alerts that paged on noise are reviewed with the owning team before they move.
Parallel running, cutover and historical data
Both stacks run side by side for a period agreed in the plan, with query results and alert behavior compared before users switch. Historical data is decided per source: migrate it, archive it to cold storage, or let it age out under the source's retention. Retention is set per tenant in Loki, and deletion rules are confirmed with your data owners.
What drives effort and duration
This table lists the factors that most change the work of moving logs to Loki, why each one matters, and how to reduce its impact before cutover.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Daily log volume and deployment mode | Loki docs place monolithic mode at up to about 20 GB per day and simple scalable near 1 TB per day. Simple scalable is removed in Loki 4.0. | Measure peak and average ingest from the current stack, then choose a mode that survives Loki 4.0. |
| Number and type of log sources | Each source type needs its own parsing, labels and shipper, and every Promtail config must be rewritten for Alloy. | Inventory sources by type, retire unused ones and standardize on a small set of shippers before cutover. |
| Dashboards and alert rules to rebuild | Each panel and alert is rebuilt in LogQL. Lucene or KQL queries from Elasticsearch-based stacks rarely translate directly. | Count and rank assets by owner, drop unused ones and rebuild critical alerts first. |
| Historical data migration | Loki cannot query logs it never stored, so moving old indexed data means re-ingestion or export work. | Decide per data class whether history moves or the old store stays read-only for a defined period. |
| Multi-tenancy and access | Tenants are separated by X-Scope-OrgID only when auth is enabled, and Loki has no built-in login layer. | Map teams to a small number of tenants and put an authenticating reverse proxy in front before cutover. |
| Object storage choice | Loki's recommended production stores are S3, Google Cloud Storage and Azure Blob. MinIO and local filesystems are not typically recommended for production. | Use the store your platform team already operates and confirm its support and durability settings with the vendor. |
| Retention periods by data class | Retention is disabled by default, so logs persist until it is enabled. Rules apply globally, per tenant or per stream, each at least 24 hours. | Set retention per data class in writing before cutover, starting from your legal and business retention schedule. |
| Compliance evidence needs | Assessors typically ask for evidence of access control, retention settings and change history for the logging system. | Agree the evidence list with your assessor early and manage retention and access configuration as code. |
| Promtail fleet replacement | Promtail reached end of life on March 2, 2026, so agents shipping to Loki must move to Grafana Alloy before cutover. | Inventory agents, move new hosts to Alloy first and migrate the rest in waves with a short dual-shipping overlap. |
Migration phases and outputs
The sequence moves each log source to Loki in controlled stages, so every stage ends with a checked output that the next stage depends on.
Inventory sources, queries and alerts
Your team and DeployOpen list every log source, the current pipeline that ships it, the dashboards and saved searches that read it, and the alert rules that fire on it. Output: a written inventory with an owner and a retention requirement for each source, reviewed by the teams that depend on those logs.
Design the target deployment
The target design fixes the deployment mode, the object storage bucket layout, the TSDB index schema, and the tenant and label model. Label design comes first because dashboards and alerts will depend on it. Output: a signed design record that names the Loki version, the tenant IDs, and the labels allowed on each stream.
Build and pilot the Alloy shippers
Alloy pipelines are built for one or two representative source groups and deployed to a pilot set of hosts or workloads. The pilot checks that labels match the design, that no unbounded values become labels, and that logs land in the expected tenant. Output: a pilot report showing ingested streams, label sets, and any dropped or misrouted lines.
Translate queries and alert rules
Each saved search, dashboard panel and alert rule is rewritten in LogQL against the approved label model and tested against pilot data. Rules that depended on fields the new label model does not expose are redesigned, not copied. Output: a translation register that maps each old query to its LogQL version, with the test result and owner for each.
Run the stacks in parallel
Both the old stack and Loki receive the same logs for a period agreed in the written scope. Event counts per source and per time window are compared, and the key queries and alerts are checked for matching results. Output: a comparison report with the accepted differences documented and signed off by the log owners.
Cut over one source group at a time
Source groups move to Alloy shipping to Loki one at a time, starting with the lowest-risk group. Each group's old shipper is disabled only after its comparison report passes and its alerts are confirmed to fire in Loki. Output: a cutover log per group recording the change date, the rollback path, and the sign-off.
Decommission the old stack and clean up retention
Once all source groups are live and the agreed read-only period ends, the old stack is shut down and its data is archived or deleted according to policy. Loki retention rules are then set per tenant or stream selector and verified in the compactor. Output: a decommission record, a confirmed retention configuration, and an evidence pack for the logging data lifecycle.
In-house or with a partner
This table compares which parts of a Loki migration teams usually keep in-house and which they often hand to a partner, with the skills each part needs, so you can match the split to your capacity and how customized your current stack is.
| Work part | Usually kept in-house | Usually taken on with a partner | Skills each part needs |
|---|---|---|---|
| Inventory of sources, dashboards and alerts | Owners of each log source confirm what must be kept and why | Partner builds the catalog of shippers, dashboards, alert rules and query patterns | Log pipeline engineering, Grafana and LogQL |
| Label design and tenant mapping | Platform owners approve label names, cardinality limits and tenant boundaries | Partner proposes label schemes and tests cardinality on sample volume | Log pipeline engineering, security and retention policy |
| Grafana Alloy pipelines | Teams that own applications and hosts review collection paths | Partner writes and tests Alloy configs replacing Promtail, Fluent Bit or hosted agents | Log pipeline engineering, Kubernetes or VM operations |
| LogQL translation of existing queries | Analysts flag queries that must return the same answers | Partner rewrites Elasticsearch or hosted query syntax into LogQL and checks results | Grafana and LogQL |
| Dashboard and alert rebuild | Operations and on-call teams sign off on panels and routing | Partner rebuilds dashboards and alert rules as code and tests firing paths | Grafana and LogQL, security and retention policy |
| Index and schema changes (TSDB, storage config) | Platform team owns the final schema and object storage decisions | Partner plans the schema change and runs the test upgrade in a non-production environment | Object storage administration, Kubernetes or VM operations |
| Parallel run validation | Service owners compare results from old and new stacks for their sources | Partner defines comparison checks, runs them and documents gaps | Log pipeline engineering, Grafana and LogQL |
| Cutover and decommission of old stack | Change approvers schedule the switch and retire old data under policy | Partner prepares runbooks, rollback steps and removes old collectors and indexes | Kubernetes or VM operations, object storage administration, security and retention policy |
| Handover and ongoing operations | Internal team takes on on-call, upgrades and retention reviews | Partner delivers documentation, runbooks and training, with optional retainer support | Kubernetes or VM operations, security and retention policy |
What goes wrong and how to prevent it
Most Loki migrations fail in predictable places: how labels were designed, how people query logs, the cutover from the old shipper, and settings that are off by default. Check each item before the first production tenant moves.
High-cardinality labels from the source index
Copying field mappings from an Elasticsearch or Graylog index design turns many fields into Loki labels. Loki indexes only labels, so values such as user IDs or request IDs inflate the index and overload ingestion and queries. Keep labels to a small, bounded set and move other fields into the log line. Check active stream counts in a test tenant before onboarding production sources.
Dashboards built on full-text search
Panels and alerts that depend on full-text search in Elasticsearch or Graylog will return slow or partial results in Loki, because Loki does not index log content. Rewrite each panel as a label selector with a LogQL line filter or parsed field. Inventory every saved search and alert rule before cutover, and mark the ones that need a label design change or a rewrite.
Promtail configs carried into Alloy
Promtail reached end of life on March 2, 2026, so its configs need to move to Grafana Alloy. Copying label names, pipeline stages and file positions without review can change which logs are collected, and gaps stay silent until someone searches for a missing event. Run the old and new shippers in parallel on a test host, compare line counts per stream, and keep the old source until the counts match.
Retention left disabled
The Loki compactor applies retention only when retention_enabled is set, so a new deployment keeps logs indefinitely by default. Migrated tenants often have no retention rule carried over from the source system, which lets object storage grow without limit. Decide retention globally, per tenant or per stream selector, with each rule at least 24 hours. Then confirm in a test tenant that the compactor deletes expired data.
No authenticating proxy in front of Loki
Loki has no built-in authentication layer, and tenant selection depends on the X-Scope-OrgID header that each client sends. Exposing the Loki port directly, or letting data sources set any tenant header, can let a client read another tenant's logs. Place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of every endpoint, and set the tenant header in the proxy from the authenticated identity.
Simple scalable mode as a permanent design
The Loki documentation states that simple scalable deployment mode is being deprecated and will be removed with the Loki 4.0 release. Choosing it for a long-term design means a second migration later, to microservices or another supported layout. Monolithic mode is documented for up to about 20 GB of logs per day, so size the first design for your actual volume and plan the layout move before Loki 4.0 arrives.
How the work differs by starting point
Teams moving from Elasticsearch usually keep the collection layer and change what happens after it. Loki indexes labels rather than full text, so Lucene habits must be rewritten as label selectors and line filters.
- Pipelines: map Logstash, Beats or Fluent outputs to Grafana Alloy, Fluent Bit or Fluentd, all of which Loki accepts, and rebuild parsing as pipeline stages.
- Queries: Kibana searches become LogQL queries, so saved searches and dashboards need to be rebuilt and checked.
- Labels: fields that were free to index in Elasticsearch can create many streams in Loki, so choose a small set of low-cardinality labels before cutover.
- Retention: index lifecycle rules do not carry over, so set Loki retention explicitly, since it is disabled by default.
- Confirm: which Elasticsearch-only features, such as certain aggregations, teams depend on, and their Grafana equivalents.
Hosted tools set the limits for export, query language and volume. The first task is to inventory what the vendor lets you extract and how much history must survive the move.
- Export: confirm the export formats, rates and any caps, since these determine how much history is migrated and how much is archived.
- Query translation: convert the vendor query language into LogQL and track each saved search and alert.
- Volume: pricing-driven filtering often happens at the source today, so decide which streams to drop, sample or route, and document each decision.
- Identity: hosted users usually sign in through vendor accounts, so plan how people and teams map to tenants behind an authenticating proxy.
- Cutover: run both pipelines for a period set by audit and retention requirements, then retire the vendor feed.
Moving the index to TSDB changes an existing cluster's index store, so the work is a schema change with a coexistence period. Loki recommends TSDB for version 2.8 and newer, and DynamoDB, Bigtable and Cassandra index stores are deprecated.
- Schema: add a TSDB schema period with a future start date so new data is written to TSDB while older chunks remain readable.
- Coexistence: older data stays queryable under the previous index until retention removes it, so plan how long both stores run side by side.
- Version check: confirm your current version and the release notes for your target before editing schema configuration.
- Testing: replay representative dashboard and alert queries against a staging copy and compare results and latency.
- Rollback: keep the previous schema configuration under version control and document how to revert it.
Simple scalable deployment is deprecated and will be removed with Loki 4.0. Teams running it must move to a supported mode before that release, and the target depends on daily volume.
- Target mode: the deployment modes documentation lists monolithic for up to about 20 GB of logs per day and microservices for very large clusters, so choose based on measured ingest.
- Components: map the separate read, write and backend targets to the new mode's components, which changes Helm values and resource requests.
- Storage: object storage and index paths can stay the same, so the move concerns compute topology rather than stored data.
- Timing: confirm the Loki 4.0 release timing from Grafana's published release information and schedule the move ahead of it.
- Validation: check ingest throughput, query latency and compactor behavior after each change.
The deployment target changes the install method and narrows the object store choices. Grafana's recommended production object stores are Amazon S3, Google Cloud Storage and Azure Blob Storage, while MinIO and the local filesystem are supported but not typically recommended for production.
- Kubernetes: install with Helm, set resource requests per component, and provision persistent volumes for caches and compactor working data.
- VMs: run binaries or containers under a service manager, own configuration backups, and assign one clear owner for compaction and retention.
- Air-gapped: confirm which object store your network can run for production, because the documentation does not typically recommend MinIO for production use.
- Artifacts: mirror container images and charts into an internal registry and pin every version.
- Confirm per environment: which recommended store is reachable from your network and whether your chosen store is covered by your support arrangements.
What you need to provide
Start with three decisions, because they set the size of every input below. First, decide which log streams move to Loki and which are archived in their current form, since archived data does not need to be queryable in Loki. Second, decide whether historical data must be backfilled or whether the migration starts from a cutover date, with the old system kept read-only for a defined period. Third, choose the Grafana access model. Teams can query Loki through Grafana with access scoped by tenant, or use Grafana Enterprise Logs for token authorization and label-based access control. That choice shapes how tenants are built.
Next, provide read access to the source system and its configuration, including index or pipeline definitions, shipper configs and any hosted-tool export settings. Supply a list of log sources with an owner, an estimated daily volume and a criticality rating for each, so the team can separate high-volume application streams from low-volume audit trails. Export existing dashboards and alert rules in a reviewable format and mark which ones people still use. Also state retention and deletion requirements by data class. Loki keeps logs indefinitely until retention is enabled, so those rules must be written and tested before retention is turned on.
Identity and tenant mapping come next. Decide which teams or systems map to which X-Scope-OrgID values and who may query each tenant once auth_enabled is on. Confirm that you can run an authenticating reverse proxy in front of Loki, because Loki has no built-in authentication layer. Provide access to the object storage bucket and approve the sizing plan, including the retention periods it assumes. Confirm which object store you will use, since the Loki documentation recommends Amazon S3, Google Cloud Storage or Azure Blob Storage for production.
Finally, reserve a test window for parallel running, during which both stacks receive the same logs and dashboards and alerts are compared. Name one owner for cutover sign-off, one owner for post-migration operations and one contact for host-side shipper changes. If hosts still run Promtail, schedule the move to Grafana Alloy now, because Promtail reached end of life on March 2, 2026. Agree early on who can approve a rollback. Without named owners, parallel running tends to end without a clear decision.
Frequently asked questions
How much does a Loki migration cost and what drives the price?
The cost is set by the written scope, and DeployOpen does not publish a price list. The main components are planning and log source inventory, the object storage and compute you provision in your own accounts, migrating log shippers (Promtail to Alloy, or Fluent Bit, Fluentd and the Docker logging driver), rebuilding dashboards and alerts in Grafana, and running old and new stacks in parallel. Storage, retention and operations time recur after cutover. Ask for a quote that separates one-time migration work from recurring infrastructure and support, and that states daily log volume, retention periods, the number of sources and whether historical data is in scope.
How long does a Loki migration take?
Timing depends on the scope agreed in writing, so no single duration applies to every migration. The main drivers are the number of log sources and shippers to move, daily log volume, how many tenants and retention rules need mapping, whether dashboards and alerts must be rebuilt, and how long the old and new systems must run side by side for comparison. Access approvals, change windows and the availability of your team also set the pace. Ask for a phased schedule with milestones in the written scope and identify which steps depend on your own staff.
Can historical logs move from Elasticsearch or a hosted logging tool to Loki?
Some historical logs can be moved, but bulk migration is often less practical than keeping the old system as a read-only archive. Export limits in the source product control how much data you can extract, in what format and how quickly, and Loki's ingestion limits on old timestamps affect any backfill. A common approach is to export a bounded window that audits or investigations need, then keep the remainder in an archive you can search. Confirm export quotas and any fees with the vendor, and decide which history is required before the scope is written.
Can our own team migrate to Loki without outside help?
A capable platform team can install Loki alone, but the hard parts are usually the migration details. The difficult work includes relabeling streams so existing queries keep working, designing tenant boundaries with the X-Scope-OrgID header, placing an authenticating reverse proxy in front of Loki because it has no built-in authentication, sizing object storage and retention, and moving every shipper without losing logs at cutover. Your team must provide access to log sources, cloud or data center accounts, an owner for each dashboard and alert, and time for testing. DeployOpen can carry out this work under a fixed written scope.
Does Promtail have to be replaced before migrating to Loki?
Yes, Promtail should be replaced. Promtail reached end of life on March 2, 2026, with no further updates or commercial support, and Grafana directs users to Grafana Alloy, its supported log shipper for Loki. Alloy is a vendor-neutral distribution of the OpenTelemetry Collector. Plan the change inside the migration: convert existing Promtail scrape configuration into Alloy pipelines, confirm that labels and timestamps still match what dashboards and alerts expect, and run both shippers side by side briefly before removing Promtail.
Must simple scalable mode change before Loki 4.0?
Plan to change it. The Loki documentation states that simple scalable deployment mode is being deprecated and will be removed with the Loki 4.0 release. Loki offers three modes: monolithic for smaller volumes (up to about 20 GB of logs per day, according to the deployment modes documentation), simple scalable with separate read, write and backend targets, and microservices for very large clusters. Choose the target mode based on daily volume, availability needs and team capacity. Confirm the Loki 4.0 timing and migration guidance in the current documentation before you set a deadline, and include the deployment mode change in the scope because it affects Helm values, storage layout and upgrade steps.
How DeployOpen scopes, delivers and hands over
DeployOpen plans and builds Loki migrations inside infrastructure you control, from your current log stack through to Loki, Grafana Alloy and the index and deployment changes Loki itself requires. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- The written scope lists each source, from Elasticsearch-based stacks or hosted logging tools, that moves to Loki.
- Scope also records daily log volume, deployment mode, object store, retention periods and the Grafana users who query logs.
- Engagements are fixed-scope, with deliverables agreed in writing before work starts, and support available as a retainer.
How we build
- Build covers Grafana Alloy pipelines replacing Promtail, since Promtail reached end of life on March 2, 2026.
- Object storage, compactor retention and tenant mapping are configured and tested against the query paths your teams use.
- Index moves to TSDB, and any simple scalable deployment is moved off before the Loki 4.0 release removes it.
How we hand over
- Handover includes configuration, runbooks, dashboards and a record of the checks used to confirm query results.
- Access is set up through an authenticating reverse proxy in front of Loki, because Loki has no built-in layer.
- Source log decommissioning follows a written plan, so the old stack is retired only after the agreed checks pass.
How we support
- Support after go-live can cover Loki version upgrades, Helm chart updates and retention checks, as a retainer.
- Security testing of the logging stack is available as a separate scope when your team needs it.
- Handover material lives in your repository, so your engineers can run and change the stack directly.
