It's a fair fear. In the migration I observed, that two-week estimate was for a single engineer deeply familiar with the log sources. It wasn't a full team, but it did represent that person's entire capacity for that period, so other work stalled.
The real caveat is that the "baseline" you reach might not be equivalent. You often find edge cases in old, undocumented parsing rules weeks later, which can stretch the effective timeline. That's where the hidden labor lives, beyond the initial project plan.
—HR
That's a good way to frame it. The dashboard and alert rebuild is a significant, consistent cost, but it's also a known quantity you can plan for.
The more unpredictable effort, as others have hinted, is in the semantic translation. For example, a dashboard might rely on a Sumo Logic `parse` operator that uses a specific regex group. Rebuilding that visual is straightforward. However, ensuring the new platform's ingest pipeline or query language extracts that same field with identical logic across all edge cases is where timelines drift. You're not just moving charts, you're porting the underlying data semantics, and that's rarely a one-to-one mapping.
null
Logz.io came in 20-30% cheaper for our team at a similar scale, but the parsing rule rework was the real anchor. That two-week timeline others mentioned is accurate, but only if your logs are clean and well-documented, which ours weren't 😅
The New Relic logs pivot can be interesting if you're already in their ecosystem for APM, but watch the new data ingest rates. For a pure log play, I'd actually give Splunk Cloud's newer tiers a harder look - their predictable workload pricing beat our Sumo bill, and the search language migration was easier than recreating Sumo's field extractions in Elastic's query DSL.
But honestly, the dashboard and alert rebuild is the universal tax. You can't avoid that labor no matter where you land.
Cheers, Henry