January 17, 2026 · 6 min read
Comparing Two Observability Tools After Actually Migrating Between Them
We migrated a client's entire observability stack between two major vendors and came out the other side with actual usage data, not marketing-page comparisons, on what each one is really good and bad at.
We migrated a client off their existing observability vendor onto a competitor, driven mostly by cost — the old vendor's per-host pricing had scaled badly as they grew their fleet. Three months post-migration, with real production usage on both sides to compare, the picture was more mixed than either vendor's marketing page would suggest, and more mixed than I expected going in.
Where the switch genuinely paid off
Cost dropped by about 45% for equivalent coverage, which was the whole point and it delivered. The new vendor's log query language was also, honestly, better for the kind of ad hoc debugging the team did most often — faster to write a quick filtered query under pressure during an incident, less boilerplate than the old vendor's query builder required for the same result.
Cheaper and faster for the common case doesn't mean better everywhere. It means better where we measured, which isn't the same claim.
Where the switch genuinely cost us something
The old vendor's distributed tracing visualization, for a specific class of deeply nested microservice calls the client's architecture relied on heavily, was noticeably better at rendering a readable trace waterfall. The new vendor's equivalent view became hard to parse past about eight nested spans, and the team's incident response for a specific recurring latency issue got measurably slower post-migration because engineers were squinting at a harder-to-read trace view instead of the old one's cleaner layout.
- Log search and ad hoc querying: new vendor won clearly, faster query syntax and better default relevance ranking.
- Cost at this client's scale: new vendor won clearly, roughly 45% cheaper for equivalent ingestion volume.
- Distributed trace visualization for deeply nested calls: old vendor won clearly, and this cost real incident-response time post-migration.
- Alerting configuration: roughly a wash, both required similar setup effort and neither's default alert rules were usable without real tuning.
If I were advising a team considering this same migration today, I'd tell them the cost savings are real and worth having, but to specifically load-test the new vendor's trace visualization against their actual service topology before committing, not just their log search experience — because log search is what every observability vendor's demo optimizes for, and distributed tracing for genuinely complex call graphs is where the real differences between platforms tend to hide until you're relying on it during an actual incident.