Migrations Are Here – Moving Away from the Legacy, Rediscovering Observability

We’re launching our automated migration experience from other vendors to groundcover, starting with Datadog.

This decision wasn’t made lightly. We debated it a lot internally, and the first objections came quickly:

Will all this heavy lifting be worth it?

Shouldn’t we ride the AI wave instead and find a more “differentiated” niche?

Why pour effort into getting users to the same value they already have elsewhere?

The truth is, heavy lifting stopped being a concern for us long ago.

If you spend enough time doing observability, you learn that heavy lifting is just part of life. Whether it’s handling unimaginable amounts of data, executing sub-second queries across terabytes, or doing state-of-the-art kernel programming, the “hard stuff” becomes the default mode.

And as for chasing hype, we believe observability isn’t a market that can afford saturation. The number of personas inside an organization who rely on it keeps growing, whileand their tolerance for fragmented or redundant tooling keeps shrinking. Observability cannot splinter into niche silos. It needs consolidation, clarity, and openness. Migration is how we help the ecosystem move toward that.

But my strongest conviction about this came when I reflected on the dozens of migrations we have already accompanied, first manually and later with internal automations we built along the way. And oh boy, the things we saw:

1. One customer asked to migrate over more than 100 monitors. Half of them hadn’t fired in six months because they were configured to look for log terms that no longer existed.
2. Several customers had metric monitors that were just mathematically wrong.
3. One customer had dashboards that looked like they were implemented to set a server on fire. They still worked fine, just took a full minute to load instead of one second.

And then there were other cases, where migration became an opportunity not just to move to a better solution but to actually improve what already existed.

That’s when it hit me:

Migration is more than simplyjust transferring a state from vendor A to vendor B.

It’s about rebuilding momentum for observability adoption at a time when it’s more pressing than ever.

You might ask why now. We have entered an era where AI generates code faster than humans can reason about it. Software no longer just executes at unimaginable speed, it changes at that speed too. Migrating your observability assets that were built before this era isn’t just a technical exercise. It’s a checkpoint, a moment to revalidate your assumptions and make sure your foundation can stand the future.

This pace of change doesn’t just make software harder to track. It also deepens hidden patterns inside the software itself. Using legacy vendor SDKs for instrumentation? Great, it is now infesting your code ten times faster than before. That leads to two main issues you should be very aware of:

1. The Cost Spiral

Every click, every feature, every new metric, it all costs more.

You are charged for volume, for indexes, for “custom” metrics, for every SKU that once felt like innovation. What begins as a journey of enablement slowly turns into a journey of constraint. You start asking permission, financial permission, just to observe your own system.

2. The Vendor Lock-In Trap

At first, it seems harmless. You adopt one more feature. Then another. A proprietary dashboard here, a custom agent there. Before long, observability isn’t just a product, it’s part of your business logic. The data models, alerts, workflows, even your team rituals, they all orbit one vendor’s gravity well.

Now combine that with the cost spiral, and you get the worst of both worlds: a platform you cannot afford to scale and cannot afford to leave.

The Path Forward

Our automated migration experience, starting with Datadog, is built from this hard-earned understanding. It’s not about cloning. It’s about liberating.

We wanted a migration that doesn’t just move assets over, but moves them into an ecosystem where they can scale indefinitely.

A world that fuses old assets with updated ones, alongside new, industry-standard, open assets.

In practical terms, it means your dashboards, monitors, and alerts can be reconstructed automatically in groundcover, mapped intelligently into our native, cost-efficient, eBPF-based platform. But conceptually, it’s much more than that.

With migrations, groundcover redefines the path of least resistance toward a modern observability stack, providing you with:

1. Full support for dual-shipping your data to us alongside your legacy vendor.
2. Automatic monitor translation, with dashboards coming soon.
3. A clear path to adopt open-source standards without blockers.

You can now plan a practical phase-out of legacy tools and move responsibly and as close to lossless as possible into a modern stack.

Final Words

As with any early launch, this is under very active development and a major focus across our organization. Our team is here to help you make use of it, answer questions, and tackle challenges together.

For those not familiar with groundcover’s philosophy of observability, here’s the short version:

1. SaaS in its current form is a broken model for observability. BYOC is the future of SaaS-like experience.
2. Instrumentation should not be a prerequisite for observability. eBPF solves that.
3. Having all data in one place is fundamental. One tool, all the data.

We hope that with this migration kit, you’ll be able to bring those principles to life as soon and as easily as possible. #notradeoffs