What If You Didn't Have to Migrate to Gigapipe to Find Out If It's Better?

Last week, Telflo published a flow that ships OpenTelemetry data to Gigapipe — logs, metrics and traces. One config, rolled out across an entire fleet of collectors.

First thought: "Nice, we have a cool integration." 🎉

Second thought took a lot longer, and it's why I'm writing this.

Every migration guide ever written gives you the same advice: Before you switch observability backends, run both. Send your telemetry to the old one and the new one at the same time. Watch them side by side for a few weeks. Check that your dashboards still render and your alerts still fire. Then cut over.

It's good advice. It's in guides written by the vendors you'd be leaving. And we say the same too.

And yet, almost nobody does it.

🤔 Two locks on the same door

I used to think there was one reason for that, and that it was the collectors. I was half right, which, it turns out, is the worst way to be wrong about this.

There were two locks on that door.

Lock one: The config. Dual-shipping means every collector in your fleet needs a second exporter. Configured right. Rolled out everywhere. Rolled back when you're done.

Lock two: The bill. If the backend you want to test also charges per gigabyte, running both means paying for the same telemetry twice.

Here's the part that matters: picking one lock never got you through the door. Say you'd automated the config perfectly back in 2023 — scripted, templated, beautiful. You still wouldn't have dual-shipped, because Finance would have asked why the observability bill doubled for a month and "to see if we could leave the current solution" is hard to explain.

And if you'd had a free destination but no way to configure 300 collectors safely? You wouldn't leave either.

Both or neither. For years it was neither.

⚡ Lock one: 300 collectors and a YAML file

This was always the boring blocker, and boring blockers are the ones stopping people.

On three nodes, adding a second exporter is an afternoon. On a real fleet it's a change-management project written in YAML, where one bad indent silently stops shipping half your traces, and you find out the following Tuesday. From a customer.

So teams read about somebody else's migration, feel a bit nervous, and stay exactly where they are. Not because they're lazy. Because the downside of getting a collector config wrong is worse than the upside of maybe finding a cheaper backend.

Telflo is a control plane for OpenTelemetry Collectors, and it takes that risk off the table. It builds, validates and rolls out collector configuration across a fleet over OpAMP. You pick a destination from a form, it checks the config is valid before it ships, and it rolls out to the fleet — and back — as one operation.

And it never touches your telemetry. Your data goes from your services, through your collectors, to your backends, exactly as before. Telflo decides the shape of the pipeline. It never becomes part of it.

That last bit is the whole reason I trust it for this job. A control plane that routes anywhere has no stake in where the data lands. It's not trying to win the destination — it's trying to be good at routing. Which is exactly what you want from the tool running your migration.

They've already built the Gigapipe side of it: a ready-made flow that ships all three signals to one base URL, behind a disk-backed queue. They also wrote up the whole Loki, Mimir and Tempo migration — read that one before you start; it's the best map of what to check while both backends are running.

So lock one: off. Adding the second destination is a form and a fleet rollout now.

Which leaves the one nobody talks about.

💸 Lock two: paying twice to ask a question

Say you're sending 5 TB/month of logs. Not a crazy amount, but a normal one.

If the backend you want to test bills per gigabyte, the overlap period costs you this much, on top of what you're already paying your current vendor. List prices, October 2026, ingest plus a month of retention:

Second destination	Cost of the overlap, per month
Grafana Cloud Pro	$2,750
New Relic Data Plus	$2,940

So "just run both for a month" actually means: spend three thousand dollars to find out whether you're allowed to leave.

Nobody signs that off. And I genuinely don't think most teams ever framed it as a decision — the number is big enough that the idea dies before it reaches a meeting.

Which is how per-GB pricing does its real work. Not by being expensive. By making the alternative expensive to even evaluate. You don't need to lock a customer in if testing the exit costs three grand.

🧮 Both locks open, finally

Gigapipe is open source. AGPL-3.0, a single Go binary, ClickHouse underneath. You can put it on a spare server this afternoon and never speak to anyone here.

Which means the real answer to "what does the second copy cost" isn't on our pricing page. It's: a box. No trial limits, no sales call, no procurement cycle, no asking Finance for three thousand dollars to run an experiment. You already know how to run a server. Point a second exporter at it.

And if you'd rather we ran it, you pay — but you pay for machine specs, and you have predictable pricing for as long as the contract is. No surprises.

Then the experiment works, and it stops being an experiment. That's the moment the paid plan starts earning its place because the things you were happy to do by hand for a fortnight are the things you do not want to be doing in six months. We run the infrastructure and the upgrades. Cold data moves somewhere cheap without you writing a cron job. Anomaly detection that knows what normal looks like at 3 am on a Sunday, instead of comparing everything to one line you drew in March. An AI assistant pointed at your own data, without you losing data sovereignty. And a specialised team of human beings who answer you when something is wrong, and you don't know why.

Run the test for 0$. Pay us when it's carrying your incidents.

So add up what it actually costs you now to find out whether a different backend is better:

• The config: a form, validated before it ships, rolled out and rolled back as one operation.

• The destination: a spare server you already own — or ours, if you'd rather not.

• The bill: predictable, regardless of what deployment you take.

Eighteen months ago that same list read: a change-management project, a procurement cycle, and three thousand dollars.

That's the news. Not the integration — the fact that testing an alternative stopped being a project and started being a Tuesday.

🔧 Getting started: it's four steps

1. Start dual-shipping. One flow in Telflo, rolled out to the fleet. Nothing changes for your existing backend.

2. Actually compare for two or three weeks. Do your dashboards render against the new data source? Do your alert rules evaluate the same? Does rate() agree? Does the LogQL you actually use — not the LogQL in the docs — parse? This is the step everyone skips and the only one that tells you anything.

3. Switch your datasource URLs once the new store holds enough history to be useful. Keep dual-shipping.

4. Stop the "old" copy when you've gone a fortnight without wanting the old one back.

💡 Three things to know before you start

1. Your old data moves only if your current vendor lets it. Nothing stops you from backfilling into Gigapipe. It takes the same APIs you're already writing to, so if you can read your history out of the old system, you can replay it in. Running Loki, Mimir and Tempo yourself? That's a backfill job, not a blocker. On a vendor that meters egress or rate-limits the export API, you'll probably start from today instead — which tells you something about that vendor, and about why you were looking for alternatives in the first place.

2. Test the queries you actually depend on. Not the ones in the documentation — your on-call dashboards, your alert rules, the panel someone built in 2023 that nobody fully understands any more. All while the old stack is still running and nothing is at stake.

3. High cardinality costs you disk, not stability. This is where ClickHouse is genuinely different. A runaway user_id label doesn't explode an index or trip a series limit the way it does on Loki or Prometheus — it uses more disk and makes some queries slower. So you get to keep the labels you actually need, instead of designing your telemetry around somebody else's ceiling. It isn't free. It's just not fatal.

✅️ Your data. Your choice.

What struck me about the Telflo flow wasn't that it exists.

It's that between their control plane and our pricing model, the last two reasons not to test an alternative quietly disappeared — and the reasons were never really technical arguments. One was a change-management risk. The other was a pricing model wearing the costume of a technical argument.

Both are gone.

Send it twice. Compare properly. Decide with evidence instead of vibes.

If Gigapipe wins, switch — and keep your collectors, your dashboards and your query languages, because we answer LogQL, PromQL, TraceQL and the Pyroscope API natively. If it loses, you've spent a few weeks and learned something true about your own stack.

The OSS build is here if you want to run it yourself · every agent and protocol we speak is here · pricing is here when you'd rather we ran it · and the Telflo flow is two clicks from running.

---

You were never supposed to need permission to find out.

Send it twice. Decide once.