# 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](https://security.googlecloudcommunity.com/community-blog-42/your-new-way-to-ingest-data-into-google-secops-5749).

## 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.](https://docs.bindplane.com/deployment)                                                              |
| Health checks    | Readiness/liveness endpoints with configurable status codes and drain behavior | [Standards-based single endpoint with TLS support and broad LB compatibility](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference) |
| Batching         | Byte-based batching                                                            | [Count-based batching](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference)                                                        |
| Buffering        | Optional disk buffering                                                        | [Persistent queue by default](https://docs.bindplane.com/production-checklist/bindplane-otel-collector/resilience#persistent-queuing)                  |
| Log Labeling     | Labels set per forwarder config                                                | [Labels set centrally via Google SecOps Standardization processor](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference)            |
| PCAP support     | Configurable in forwarder config                                               | [TCP ingestion supported; PCAP parity in development](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference)                         |

## Migration Workflow

This section focuses on the Forwarder → Bindplane migration process. For installation and configuration details, visit the [Getting Started with Bindplane page](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference).

#### 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.](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference)
* 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.](https://docs.bindplane.com/integrations/processors)

#### 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.](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference)

#### 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.](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference)

#### 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.](https://docs.bindplane.com/how-to-guides/google-secops/broken-reference)
* 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.

{% hint style="success" %}
To get the most out of your deployment, see the [Using Google SecOps with Bindplane Best Practices](https://docs.bindplane.com/how-to-guides/google-secops/using-google-secops-with-bindplane-best-practices) guide.
{% endhint %}