Migration engineers who decide with you what to keep, retire and rebuild.

A 60-widget Splunk dashboard that took 12 hours to convert now takes 45 minutes.

12h → 45mina Splunk dashboard, before and after
<1hper dashboard, from every source we timed
75,000+assets moved since 2023, counted once
300+migrations and onboardings since 2023

Under an hour from every source we timed

Engineer time to convert one 60-widget benchmark dashboard, before and after. Conversion and review only; getting the data flowing is a separate clock, further down.

Before: team baseline, January 2026Agentic build: LLMs + CX CLI + CX Skills, October 2026
  • Splunk12 h45 min16×
  • New Relic6 h40 min9×
  • Datadog3 h35 min5×
  • Grafana1 h35 min1.7×

On real customer migrations

−55%days per dashboard delivered, 2025 to today

4.0 days 1.8 days

Median calendar days from start to delivered for each dashboard, including waiting on data and customer review. Finished migrations, all sources; 2026 H2 to 12 Oct.

The drop followed the April 2026 rollout

The agentic build pairs LLMs with the CX CLI, which helps translate each query into DataPrime and checks every widget against the customer's live tenant, and with CX Skills, which carry what the team has learned across 300+ engagements.

  1. Splunk16×12 h → 45 min
  2. New Relic9×6 h → 40 min
  3. Datadog5×3 h → 35 min
  4. Grafana1.7×1 h → 35 min
Solid points are the team's January baseline and the timed October 2026 run, engineer time per 60-widget dashboard. The months between are estimates shaped by the rollout date, not timed runs.

What the speed unlocks

The agentic build frees the migrations team's time for the rest of the migration, which they work through with your team.

Your team

  • Decides which services, dashboards, alerts and SLOs must be ready before the old vendor is switched off.
  • Decides what to keep, retire or rebuild.
  • Signs off each converted asset. The migration closes only when you have agreed it is done.

The migrations team

  • Works out with you what each group of assets is used for.
  • Builds the plan with you: what moves first, what waits for data and what is retired.
  • Checks every converted asset twice: once by the engineer who built it, then by a second engineer.
  • Creates converted alerts switched off, so nothing pages your on-call until a person has reviewed the threshold.
  • Flags anything that does not convert cleanly, with evidence.

One example dashboard, to show the steps. The calculator below assumes about 10% of assets are dropped as unused or duplicate.

75,000+ assets moved since 2023

By asset type, counted once

  • Alerts66,000+
  • Dashboards4,700+
  • Parsing rules2,000+
  • Other assets2,200+

Engagements by source platform

  • Datadog55
  • Grafana40
  • New Relic23
  • Elastic20
  • Splunk19
  • Sumo Logic12
  • Multiple vendors16
  • Other vendors33
  • Low-touch onboardings110
  • Cross-Coralogix migrations25

Includes the largest single alert migration we have run: about 41,000 alerts across production and non-production for one customer. Multiple vendors means more than one source in a single engagement. Other assets: saved searches, webhooks, reports, recording rules and automations.

Bring the data in first

The slowest step is getting your data into Coralogix. Integrations and Extensions let you do that yourself, with prebuilt content to start from. Moving from a vendor agent to OpenTelemetry can rename fields and metrics, so custom dashboards and alerts are built once the data is in, then validated by the customer before sign-off.

  1. 1 · Integrations + ExtensionsSelf-serve

    Connect your sources with Coralogix integrations, then deploy extension packages for prebuilt dashboards, alerts and parsing rules.

  2. 2 · Agentic build: LLMs + CX CLI + CX SkillsUnder an hour

    Per dashboard. Each one is built and checked against live data, then reviewed by an engineer.

Why an engineer reviews the result

A translated query that passes a syntax check can still render nothing. Since April 2026 the agentic build runs each widget on live data, applies the fixes CX Skills already know, and hands the result to an engineer.

  • Read-only on the source platform.
  • Engineer approval before anything is created in Coralogix. You validate each asset before it is accepted.
  • Checked on live data before hand-over. Anything that does not convert cleanly is flagged with evidence.
  1. LLM onlyTranslates the query, blindIt cannot see the data, so the widget renders empty.rows: none
  2. + CX CLITranslates with schema help, then runs it liveDataPrime guidance, then the query on the live tenant. The widget fills.$ cx logs query … ok
  3. + CX SkillsApplies fixes the team has seen beforeAn OpenTelemetry field rename, corrected on sight.host → host.name
  4. Engineer and your teamAgree what shipsAn engineer goes through each result and anything flagged with you, then lands it in Coralogix.approved → Coralogix

Prepare before you decommission

Conversion is the fast part. What slows a migration is what has to be true before it starts: data flowing into Coralogix, an inventory you trust and a scope that holds. The migrations team sets the inventory and the scope with you.

Migrations delivered on time

3 in 4finished on or before their planned end date

The three causes post-migration reviews name most. 27 of 46 reviews named at least one.

  1. 1Data not onboarded before migration began14 of 46
  2. 2Customer validation took longer than expected11 of 46
  3. 3Scope changed mid-migration10 of 46

96 finished migrations with a planned end date, 2024 to 2026. Reasons from 46 post-migration reviews; a review can name more than one.

Prepare your migration

  1. Audit what you run today

    Inventory the services, dashboards, alerts and SLOs that must be ready in Coralogix before the existing observability vendor is switched off. What nobody uses is retired; what remains is the scope.

    • Services
    • Dashboards
    • Alerts
    • SLOs
    • Inventory complete

  2. Start a trial and plan the migration with us

    Sign up, then build the migration plan with the migrations team: what moves first, what waits for data and what is retired.

    Start free trial

How big is your migration?

Enter what you run today. The estimate is calendar time for the build once your data is in Coralogix, plus your team's review. Getting the data in comes first and is shown on its own. Dashboard effort is the October benchmark figure for your source, and assets a migration usually drops as unused or duplicate are left out.

Defaults are the median migration we have delivered: 25 dashboards and 75 alerts.

Calendar time to build, once your data is in
0.5–1 weeks, plus your review
Before the build: getting your data in (median from kickoff, not in the figure above)
3.5 weeks
Assets to migrate (≈10% dropped during migration)
90 of 100
Build and checks (engineer time to convert and review; scoping with you is not counted)
0.5–1 engineer-weeks
Your team's review (11 of 46 post-migration reviews say customer validation took longer than expected)
set by you

Estimate only. Data-in is the median from recent migrations; dashboard time is from the October benchmark; alert time is the migrations team's planning figure. We have no measured figure for customer review, so it is left to you.

Start free trial

How this is calculated

 
effort_hours   = (25 dashboards × 0.6 h + 75 alerts × 6 min) × (1 − 0.1)
               = 20.3 h
engineer_weeks = 20.3 h ÷ 32 h = 0.6   range ×0.8 … ×1.25 → 0.5–1
build_weeks    = engineer_weeks ÷ 1 engineer → 0.5–1
data_in        = 3.5 weeks median from kickoff, before the build, not added
assets_after   = (25 + 75) × (1 − 0.1) = 90 of 100
  • 0.6 h per Datadog dashboard is engineer time to convert and review one benchmark dashboard, from the October run for each source.
  • 6 min per Datadog alert is the migrations team's planning figure for converting and reviewing one alert or monitor: 12 min, scaled for the source (Splunk 8.4, New Relic 7.2, Datadog 6, Grafana 4.8).
  • 10% of scoped assets are dropped during migration as unused or duplicate, so they are left out of the effort.
  • 32 h is one focused engineer-week; the range spans ×0.8 to ×1.25 of the point estimate.
  • 3.5 weeks is the median wait from kickoff until data is flowing in Coralogix in recent migrations. It comes before the build and is not added to the estimate; if your data already flows into Coralogix, the build can start straight away.
  • Your review is not in the number. We have no measured figure for it; 11 of 46 post-migration reviews say customer validation took longer than expected.

Engineer effort covers conversion and engineer review. Calendar time divides it across your engineers. Neither includes rework after customer feedback or your team's own review time.