Serverless versus Hosted versus lift-and-shift for a self-managed 8 TB/day estate

Judge by hard requirements, not preference. Three of the stated needs are Hosted-shaped:

1. Point-in-time index restore. On Serverless you do not manage cluster snapshots; the platform handles durability, but you cannot restore a specific index to a chosen snapshot. This has been needed twice this year - it is a hard constraint, not a nice-to-have.
2. 400-day tiered retention with forecastable cost. Hosted lets you build hot to warm to cold to frozen (searchable snapshots, Enterprise licence) and price each tier. On Serverless lifecycle is platform-managed and you tune project-level retention rather than designing tiers, which changes the cost model from something you engineer to something you select.
3. Cross-cluster search to a partner. Serverless uses a different cross-project mechanism; verify partner-side compatibility and network path before betting a production dependency on it.
4. Twelve ML jobs. Hosted gives dedicated ML nodes and job-level sizing; confirm feature parity and job limits on the Serverless project type before migrating them.

Recommendation: Elastic Cloud Hosted with autoscaling for hot/content, plus a frozen tier for the 400-day security indices. Autoscaling does not cover ML nodes, so size those explicitly.

Where Serverless wins: a brand-new, isolated Observability workload with no restore requirement, no cross-cluster dependency and modest retention - there the removal of shard, node and lifecycle management is a real saving. A split estate is a legitimate answer if it is chosen deliberately and the boundary is documented.

What breaks. The repository is NFS; Elastic Cloud cannot mount it. A snapshot repository must be an object store the deployment can reach (S3, GCS or Azure Blob). Second, snapshots cannot be restored into an older version - the target must be at the same or a newer version, so the source needs upgrading first. Third, a snapshot carries indices and data streams but not Fleet policies, Kibana saved objects, API keys, role mappings, alerting rules or ML job definitions.

Sequence.

1. Upgrade self-managed to the target version, run the upgrade/migration assistant and clear mapping and template deprecations before snapshotting.
2. Create an object-store repository, register it on both sides, take a final snapshot and restore into the new deployment. Check _tier_preference on every restored index - tier names that do not exist in the target topology leave indices unassigned.
3. Re-create the non-data assets: Fleet policies and integrations, Kibana objects via export/import, API keys and role mappings, alerting rules, and the 12 ML jobs and their datafeeds pointed at restored indices. Re-register the partner remote cluster and open the network path.
4. Cut over ingestion by dual-shipping: point Beats/Elastic Agent outputs at the new endpoint and leave the old pipeline running for several days, comparing per-data-stream document counts. At 8 TB/day, a remote reindex backfill is not viable - it would take weeks and contend with live ingest. The snapshot is the backfill.
5. Rehearse the acceptance criterion: restore a single index into a scratch deployment, timed end to end, before cutover. That is the capability the security team is actually buying.

Arithmetic first. 8 TB/day x 400 days is roughly 3.2 PB before any reduction or compression. No tier makes that cheap if it is all hot storage, so the design is about which bytes live where.

Tier plan. Hot: 3 days (rollover at 50 GB or 1 day), 1 replica, high-performance storage. Warm: 30 days, forcemerge to one segment, best_compression, 1 replica. Cold: 90 days, 1 replica (zero is possible but you lose resilience on data that is still searchable on demand). Frozen: 400 days as partially mounted searchable snapshots in object storage - this is the only tier that makes the 3.2 PB number affordable, and it requires an Enterprise-level licence. Confirm the entitlement before presenting the design.

Reduce at the source. Network flow logs are usually the largest and least-read stream. Aggregate flows into rollups rather than storing raw per-flow events, and drop repeated identical firewall denies in an ingest pipeline before indexing. This changes the multiplier, not just the tier price.

The surprises. (a) The frozen tier and its licence; (b) autoscaling on Hosted covers hot/content tiers, not ML nodes, so the 12 jobs need explicit sizing and cannot query frozen data; (c) replicas double vector and text storage on every tier except frozen; (d) hot-only pricing for 3.2 PB is roughly an order of magnitude above the tiered design - if the CIO has seen a hot-only quote, the tiered number will look implausible and needs the assumptions shown alongside it.