Migrating from the Deprecated Google Chronicle Forwarder

Google SecOps is officially deprecating the Chronicle (SecOps) legacy forwarder in January 2027. All data ingestion will transition to OpenTelemetry (OTel) collectors using Bindplane as the official ingestion platform. This shift provides a more scalable, standardized, and manageable foundation for collecting log and telemetry data, with stronger security controls and long-term support.

For background on the timeline and rationale, see Google's deprecation announcement.

Differences at a Glance

The Chronicle Forwarder and Bindplane deliver similar ingestion outcomes but differ in several operational areas that affect migration planning.

Area	Chronicle Forwarder	Bindplane
Deployment model	Docker container only	Linux/Windows services, Kubernetes, Docker, etc.
Health checks	Readiness/liveness endpoints with configurable status codes and drain behavior	Standards-based single endpoint with TLS support and broad LB compatibility
Batching	Byte-based batching	Count-based batching
Buffering	Optional disk buffering	Persistent queue by default
Log Labeling	Labels set per forwarder config	Labels set centrally via Google SecOps Standardization processor
PCAP support	Configurable in forwarder config	TCP ingestion supported; PCAP parity in development

Migration Workflow

This section focuses on the Forwarder → Bindplane migration process. For installation and configuration details, visit the Getting Started with Bindplane page.

Step 1: Inventory your existing deployment

• Review existing Chronicle Forwarder deployments.

• Note log types, ports, ingestion labels, and PCAP usage (if applicable).

• Identify the volume of data per forwarder for sizing purposes.

Step 2: Deploy Bindplane alongside forwarder (dark launch)

• Install Bindplane on the same or equivalent hosts.

• Recreate equivalent input sources in Bindplane. See supported sources here.

• Keep Chronicle Forwarder active during this stage to minimize risk.

Step 3: Migrate any regex filters and routing

• Migrate any existing Chronicle regex filters.

• Consider adding other processors to enrich, filter, or route logs as needed to match your operational workflows.

• See more processors here.

Step 4: Configure Google SecOps Standardization Processor

• Define log type, namespace, and ingestion labels.

• Ensure alignment with existing Forwarder values to maintain UDM parsing.

• Optionally, add an ingestion label to make it easier to distinguish Bindplane traffic from Chronicle Forwarder logs during testing.

• More information on the Google SecOps Standardization Processor here.

Step 5: Adjust batching and queueing

• Chronicle batches by bytes and uses optional disk buffering; Bindplane batches by log count and buffers to disk by default using a persistent queue for durability during outages.

• Start with Bindplane SecOps batching defaults. Then tune batch count, queue size, and number of consumers based on observed throughput and recovery needs.

• More information on batching and queuing here.

Step 6: Update load balancer health checks

• Chronicle uses /meta/ready and /meta/available with 204 responses and drain behavior.

• Bindplane uses a single health check endpoint (default /, port 13133) with 200 response and optional TLS/mTLS. See more here.

• Update Load Balancer configuration to avoid failed probes and outages.

Step 7: Cutover in stages

• Run both forwarder and Bindplane in parallel.

• Route a portion of traffic to Bindplane, then scale up gradually.

• Validate event counts, throughput, and SecOps API performance before full cutover.

Step 8: Validate and rollback plan

• Confirm parity of event volume and latency between systems.

• Keep forwarder in LB target groups for easy rollback.

• Once stable, decommission Chronicle Forwarder.

To get the most out of your deployment, see the Using Google SecOps with Bindplane Best Practices guide.