Plan a Logstash to Elasticsearch Ingest Pipeline Migration

You are an Elastic architect who has migrated processing between Logstash and Elasticsearch ingest pipelines and knows the trade-offs precisely.

I will provide:
- Current Logstash pipeline: the filters in use (grok, dissect, date, mutate, geoip, enrich/lookups, ruby, aggregate), event rate, and outputs
- Cluster shape: dedicated ingest nodes or not, current CPU headroom, and version
- Motivation: reduce Logstash footprint, lower latency, simplify ops, or cost
- Delivery/durability requirements (buffering, at-least-once, backpressure)

Your job:

1. **Decide what can and can't move** — map each Logstash filter to an ingest processor equivalent (grok/dissect/date/geoip/set/rename/script/enrich) and flag the ones with no clean equivalent (aggregate/stateful ruby, multi-event joins, complex conditional routing, output buffering) that must stay in Logstash.

2. **Weigh the trade-offs honestly** — Logstash gives buffering (PQ), backpressure, multi-output fan-out, and offloads CPU from the cluster; ingest pipelines give simpler topology and lower latency but push CPU onto ES and have no queue. Recommend a split, not a religion.

3. **Design the target processing** — the ingest pipeline definition (processors + on_failure handlers so a bad document is captured, not silently dropped), and how the index template/default_pipeline wires it in.

4. **Preserve durability** — keep Logstash (or Beats/Agent with its own buffering) in front for backpressure and at-least-once delivery; be explicit that ingest pipelines add no buffering.

5. **Plan a shadow-and-diff cutover** — dual-write to a shadow index processed by the ingest pipeline, diff documents field-by-field against the Logstash output, reconcile differences (processor semantics, timezones, geoip DB versions), then cut over and monitor.

6. **Define rollback + monitoring** — how to revert default_pipeline, and the ingest/index metrics (ingest processor failures, indexing latency, node CPU) to watch post-migration.

Output as: (a) a per-filter migrate/keep decision table, (b) the trade-off analysis, (c) the target ingest pipeline with on_failure, (d) how durability is preserved, (e) a shadow-diff cutover + rollback plan. Stress that ingest pipelines have no queue and require field-level validation before cutover.