Source: https://benchmarks.coralogix.com/migration-benchmarks # 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. - LLMs - CX CLI - CX Skills 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. ## 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. How one asset moves. Discovery and scope: the source dashboard's eight widgets are tagged by use (on-call, SLO, capacity, duplicate, unused 90 days). Migrate: the Splunk query index=web status>=500 | timechart span=5m count by host becomes DataPrime: source logs | filter $d.status >= 500 | groupby $m.timestamp.roundTime(5m), $d.host aggregate count() as errors, checked against the tenant. Validate and sign-off: three widgets are dropped, five move into the Coralogix dashboard, and an engineer and the customer sign off. 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 66,000+ alerts, 4,700+ dashboards, 2,000+ parsing rules, 2,200+ other assets - Alerts**66,000+** - Dashboards**4,700+** - Parsing rules**2,000+** - Other assets**2,200+** Engagements by source platform - Datadog**55** - Grafana**40** - New Relic**23** - Elastic**20** - Splunk**19** - Sumo Logic**12** - Multiple vendors**16** - Other vendors**33** - Low-touch onboardings**110** - Cross-Coralogix migrations**25** 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 · Integrations + Extensions**Self-serve** Connect your sources with [Coralogix integrations](https://coralogix.com/docs/integrations/), then deploy [extension packages](https://coralogix.com/docs/user-guides/getting-started/packages-and-extensions/extension-packages/) for prebuilt dashboards, alerts and parsing rules. 2 · Agentic build: LLMs + CX CLI + CX Skills**Under 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 only**Translates the query, blind**It cannot see the data, so the widget renders empty.rows: none 1. + CX CLI**Translates with schema help, then runs it live**DataPrime guidance, then the query on the live tenant. The widget fills.$ cx logs query … ok 1. + CX Skills**Applies fixes the team has seen before**An OpenTelemetry field rename, corrected on sight.host → host.name 1. Engineer and your team**Agree what ships**An 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 4**finished on or before their planned end date 96 finished migrations, one dot each: 71 on or before plan, 25 ran over. 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 1. 2Customer validation took longer than expected11 of 46 1. 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 #### 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 #### 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. 1. [Start free trial](https://dashboard.app.cx498.coralogix.com/signup-v2/email?utm_source=coralogix-benchmarks&utm_medium=referral&utm_campaign=coralogix-benchmarks&utm_content=migration-benchmarks-prepare) ## 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. Migrating from Datadog New Relic Splunk Grafana Dashboards Alerts and monitors Migration engineers 123456 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](https://dashboard.app.cx498.coralogix.com/signup-v2/email?utm_source=coralogix-benchmarks&utm_medium=referral&utm_campaign=coralogix-benchmarks&utm_content=migration-benchmarks-calculator) ### 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.