A reproducible migration checklist: profile data volume and query habits, evaluate a domestic stack, migrate via dual-write, and close out with acceptance criteria.
The biggest risk in migrating a log platform isn't technical — it's discovering after the move that the new tool is harder to use. So spend a week profiling three things before you start:
The output is a checklist you'll reuse as the acceptance criteria later — don't decide anything on gut feeling. A common mistake is sizing the new platform by disk alone; a search that takes 30 seconds to return will frustrate users far more than a smaller disk. Write down query-latency expectations too, and make them measurable: "top-N error queries must return within 2 seconds at the 90th percentile" is a target you can actually verify.
Migration is rarely just swapping one piece of software — it's usually one step in replacing the whole stack. Observe is written in Go and ships as a single binary, so the adaptation cost on domestic hardware is low. A typical combination:
Focus on three things when choosing: whether write and search performance hold up on ARM, driver compatibility with the database, and whether the vendor provides adaptation and test reports for the sovereign environment. Don't trust spec sheets alone — run a benchmark with your real data volume, at your real retention window, and watch both ingestion throughput and query latency. ARM servers handle log ingestion well, but CPU-bound operations like regex-heavy parsing can behave differently from x86, so test with the same parsing rules you use in production.
A hard cutover is risky. Prefer dual-write plus gradual rollout:
Watch storage cost and shipper resource usage during dual-write — you're temporarily paying for both. Use shippers that support multiple outputs and hot-reloadable configs; Vector and the OTel Collector both do, so changing outputs doesn't require restarting the process. A practical tip: start the gray period with a read-heavy team (NOC, support) rather than the team that writes the most alerts, so you validate search ergonomics before you validate alert reliability.
Two pitfalls to catch in the first week of gray-period data: field mappings that don't line up (a field named level on one side and severity on the other breaks every saved query), and timezone skew between the shipper, the old ES and the new platform. Both are cheap to fix now and painful to fix at cutover.
Acceptance should cover at least these items:
Write the rollback plan in advance too: keep the old ES read-only for at least two weeks, define explicit triggers (the new platform down for 30 consecutive minutes, or major query-result divergence), and rehearse the rollback once. The end of a migration isn't "the data moved" — it's "we can get back quickly when something breaks."