Migrate from Sumo Logic to Grafana Loki

Monolithic mode runs Loki as a single binary that handles reads, writes and compaction in one process. Grafana's deployment modes documentation places it at up to about 20 GB of logs per day, which makes it the simplest option for a pilot, a single business unit or a set of non-production environments. Operating it means one service to deploy, upgrade, monitor and back up, plus a single object store bucket for chunks and index.

• Operational footprint: One binary and one configuration set reduce the number of moving parts your platform team must patch.
• Scaling ceiling: Once daily ingest approaches the documented range, you will need to move to a different mode, so plan that step before cutover.
• Failure domain: A single process is a single point of failure unless you run more than one instance behind a load balancer and design for it.
• Retention and storage: Retention is set in the compactor and is off by default, so configure it deliberately even at small volumes.
• Access control: Loki has no built-in authentication, so put an authenticating reverse proxy in front of it in every mode.

Confirm with Grafana whether your measured daily ingest, including bursts during peak hours, fits within the monolithic range before you commit to this mode.

Simple scalable mode splits Loki into separate read, write and backend targets, so each path can be scaled on its own. Grafana's documentation places it at up to approximately 1 TB of logs per day. The Loki documentation states that this mode is being deprecated and will be removed with the Loki 4.0 release, so it is a poor choice for a long-lived platform that has no planned migration path.

• Mid-range volume: It covers the gap between a single binary and very large clusters for teams that expect steady growth.
• Deprecation status: Removal with Loki 4.0 means any production deployment will need a second migration to another mode.
• Operations: Read and write targets scale independently, but you still manage the backend and the object store integration yourself.
• Upgrades: Plan upgrades carefully across the separate targets and check the release notes for each version you adopt.
• Alternative path: If your volume sits in this range, the microservices mode is the supported long-term route, with more operational complexity.

Ask Grafana for its current guidance on this mode, the expected timing of Loki 4.0 and the recommended migration path from simple scalable to microservices before you size your cluster.

Microservices mode runs each Loki component as its own deployment, which Grafana documents for very large clusters. It gives the most control over scaling and isolation of ingestion, querying, compaction and index handling. The cost is operational: you run many components, need orchestration (typically Kubernetes), and must monitor each component's health and resource use.

• Isolation: Query load does not compete directly with ingestion, which helps when many teams search at once.
• Team skills: Expect to need Kubernetes, Helm or equivalent tooling, and staff who can tune object store and cache settings.
• Cost drivers: Compute for each component, object storage capacity and request volume, and the engineering time to operate the cluster all grow with scale.
• Upgrade discipline: More components mean more coordinated rollouts, so test upgrades in a staging cluster first.
• Observability of Loki itself: Monitor the Loki components with a separate metrics stack so you can see failures before users report them.

Before committing, ask Grafana and your implementation partner to confirm the component layout, sizing assumptions and object store requirements for your measured volume and query concurrency. Compare that against the staff time your team can realistically commit.

Teams whose Sumo Logic usage centers on application logs usually have a small number of services, structured or semi-structured JSON output, and searches built around request IDs, error levels and user or tenant fields. Loki handles this well when those fields are kept out of the stream labels and parsed at query time, because high-cardinality labels are the most common cause of slow or costly Loki deployments. Sumo Logic users often find their field extraction rules and parse operators have no one-to-one equivalent, so each search must be rewritten as a LogQL pipeline.

• Collector choice: Applications that already log to stdout can usually be picked up by Grafana Alloy or Fluent Bit without code changes, while file-based logs need a tail source and a stable position file.
• Label discipline: Keep labels to service, environment and namespace-level values; move request IDs and user identifiers into the log line.
• Parsing: Rebuild Sumo Logic parse and field extraction rules as LogQL json or logfmt stages, and test them against sample lines before cutover.
• Dashboards: Recreate panels in Grafana against Loki queries, and compare results for a known incident window before retiring the Sumo Logic version.
• Retention: Set per-stream retention in the compactor, since Loki keeps logs indefinitely until retention is enabled.

Before you start, confirm the daily volume by service with your Sumo Logic usage report, because it determines which Loki deployment mode you need.

Infrastructure teams often send system logs, container stdout, load balancer and database logs, and audit streams from many hosts and clusters. Loki's label model fits this well because Kubernetes metadata such as namespace, pod and container maps directly to stream labels, and the Alloy or Fluent Bit daemon set can attach those labels automatically. The work shifts from rewriting searches to standardizing collection across heterogeneous hosts, which is where most of the effort in a migration like this tends to sit.

• Daemon set rollout: Deploy the log agent as a DaemonSet or on each host through configuration management, and keep the collector configuration in version control.
• Label mapping: Decide which Kubernetes labels become Loki labels and which stay as metadata, based on the cardinality of each.
• Non-container sources: Hosts running syslog, journald or vendor appliances need separate source definitions, and each needs a test that confirms timestamps and time zones.
• Deployment mode: Simple scalable mode is deprecated and removed with Loki 4.0, so plan for monolithic or microservices deployments for new installs, and confirm the current guidance in the Loki deployment modes documentation.
• Object storage: Choose Amazon S3, Google Cloud Storage or Azure Blob Storage for production, and treat MinIO or filesystem storage as needing extra justification.

Check whether your Kubernetes platform team owns the collector rollout, because that decides who maintains the configuration after go-live.

Some teams use Sumo Logic Cloud SIEM for detections, alert triage and compliance reporting, not only for search. Loki is a log aggregation store and query layer, not a SIEM, so it does not replace detection content, correlation or case handling on its own. Moving only the raw logs into Loki can leave security alerts without an owner, so the security dependencies need a separate decision before any collector is retired.

• Detection content: Export or document every Sumo Logic rule and scheduled search that feeds an alert, and assign each one a target in the new stack.
• Security tooling: Teams that need correlation, file integrity monitoring or vulnerability detection should review the Wazuh sibling page, and teams that need a search-and-dashboard SIEM should review the OpenSearch sibling page.
• Alert routing: Grafana alerting can notify on LogQL queries, but confirm that it covers every alert channel your SOC currently uses.
• Auditability: Keep a record of which detections moved, when, and who approved the change.
• History: Sumo Logic CSV exports are capped at 100,000 rows per search, so historical security evidence needs a separate export plan.

Confirm with the SOC lead which alerts must keep firing during cutover, because running two detection paths in parallel is usually safer than a single switch.

Organizations that must keep logs inside their own network, such as banks, healthcare providers and public agencies, often choose Loki because the data path stays under their control and the storage sits in an object store they already run or approve. The compliance question is less about the software and more about who can read the logs, how access is authenticated and how retention is enforced. Loki has no built-in authentication, so access control, tenant separation and audit logging must be designed around it.

• Authentication layer: Put an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of Loki, because the documentation says you must do this yourself.
• Tenancy: Enable auth_enabled only when you need per-tenant separation, and enforce the X-Scope-OrgID header at the proxy so clients cannot choose their own tenant.
• Grafana access: All editions support LDAP, generic OAuth, Entra ID and Okta, but SAML, team sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud, so confirm which of these your identity provider requires.
• Hardening: Apply the Grafana security hardening guidance and run Grafana against MySQL or PostgreSQL rather than SQLite.
• Licensing review: Loki is AGPLv3, so have legal review how your use and any modifications interact with that license.

DeployOpen prepares controls and evidence for assessments, but independent auditors issue any attestation, so ask your auditor which of these artifacts they expect.