Splunk to Datadog migration
without losing sight of production.
A migration that leaves a gap in visibility is a window for the incident nobody sees. We map what Splunk actually does for your teams, rebuild the parts that matter in Datadog, and run both side by side until cutover is safe. Critical Cloud is a Datadog Advanced Partner and the world's first Powered by Datadog accredited MSP.
Not everything in Splunk needs to move
A Splunk to Datadog migration is an inventory problem before it is an engineering one.
A Splunk estate that has been running for a few years holds saved searches, scheduled reports, alerts and dashboards built by people solving the problem in front of them. Every one was created for a reason. Some of the reasons left with the people who had them.
Copy all of it across and the new platform inherits the old noise: alerts that fire into a channel nobody reads, dashboards nobody has opened since the incident they were built for, searches that return nothing useful.
So the first job is finding out what Splunk actually does for your teams. Which searches people run. Which alerts someone acts on. Which dashboards get opened when something breaks. That is what gets rebuilt in Datadog. The alerts nobody acted on in Splunk do not get migrated.
How the migration runs
Five stages, from discovery to handover. Production stays visible throughout.
Discover Map what Splunk does today Discovery and inventory: sources, searches, alerts, dashboards and the teams that depend on them.
We inventory the log sources feeding Splunk and the searches, alerts and dashboards built on them, then find out which of those your teams actually use. The output is a list of what moves, what is replaced by something better in Datadog, and what is retired.
Design Design ingestion, pipelines and tags Ingestion design, pipelines and parsing, and a tagging strategy that works across logs, metrics and traces.
Logs arrive in Datadog through pipelines that parse and enrich them, tagged so the same service name works in logs, metrics and APM. This is also where each source gets a decision about indexing and retention, which is where most of the future bill is set.
Rebuild Rebuild the searches, alerts and dashboards that matter Rebuilt by engineers who understand what each one was for, not converted line by line.
Splunk's search language and Datadog's query syntax are different, and a saved search is rebuilt by someone who understands what it was for. Monitors are recreated with thresholds that suit the environment, dashboards are rebuilt around how your teams work, and the alerts that matter get runbooks.
Validate Run side by side, then cut over Side-by-side validation and a controlled cutover plan, so there is no gap in visibility.
Splunk and Datadog run in parallel while the rebuilt monitors and dashboards are checked against the old ones. Cutover follows an agreed plan and order. Splunk stays in place until Datadog has shown it sees what Splunk saw.
Hand over Hand over, or keep us on Runbooks and enablement for your team, HyperCare after cutover, or Managed Observability.
Your team gets enablement and documentation for what was built. HyperCare can follow as a two-week sprint to fix the instrumentation gaps and carry-over alert configurations that only show up under real traffic. About HyperCare.
When the migration is part of a wider Datadog rollout, LaunchPad runs it as one project-managed implementation across three phases: Assess, Pilot and Scale. About LaunchPad.
The cost comparison is about what you index
Comparing licences misses the decision that sets the bill.
Most Splunk to Datadog cost comparisons put one licence next to the other. The bigger lever is what you choose to index.
Datadog bills log ingestion and log indexing separately. Ingesting a log is cheap. Indexing it, so it is searchable at speed for a set retention period, is where log cost lives. A migration that indexes everything Splunk held reproduces the old bill shape on a new platform.
A migration that decides source by source does better: what needs to be searchable, for how long, what can sit in an archive or Flex Storage, and what only ever feeds a count and can become a metric. How Datadog bills each of those is set out in our Datadog pricing explained guide and in Datadog logs pricing.
How a migration is scoped
Scope and timeline come after discovery, not before it.
There is no tool in this process that converts a Splunk estate into Datadog. The work is engineering, and how much of it there is depends on how many sources, searches, alerts and teams are involved. We agree scope, access and what done looks like after discovery, and quote the work then.
If you want every Splunk search and alert copied across one for one, we are the wrong choice. We will tell you which parts are not worth bringing.
Datadog consultancy
Migration is one of the projects we take on. Assessments, implementations, cost fixes and improvement engineering are the others, with the option to have us run Datadog 24x7 once the project ends.
Read about our Datadog consultancy →Frequently asked questions
Direct answers to the questions we are asked most often.
Q How long does a Splunk to Datadog migration take?
It depends on the estate: the number of log sources, saved searches, alerts and dashboards in use, and how many teams rely on them. We agree scope and timeline after discovery, once we know what Splunk actually does for your teams, rather than quoting a number before anyone has looked.
Q Do you migrate every Splunk alert and dashboard?
No. We migrate the searches, alerts and dashboards your teams actually use. Alerts nobody acted on in Splunk do not get migrated, because moving them only moves the noise.
Q How do you keep production visible during the migration?
Splunk and Datadog run side by side while the rebuilt searches, monitors and dashboards are validated against the old ones. Cutover then follows a plan, in an agreed order, so no service is left unmonitored between the two tools.
Q Will Datadog cost less than Splunk?
That depends less on the licence than on what you index. Datadog bills log ingestion and log indexing separately, so the cost is shaped by which logs need to be searchable and for how long. A migration that indexes everything Splunk held reproduces the old bill shape. Deciding source by source what to index, what to archive and what to turn into metrics is where the cost is decided.
Q What happens after cutover?
You choose. We hand over with runbooks and enablement so your team can run Datadog, and HyperCare can follow as a two-week sprint to fix the instrumentation gaps and carry-over alert configurations that show up under real traffic. Or we run Datadog for you as Managed Observability.
Q Where are you based?
Critical Cloud is headquartered in Cardiff, with offices in London and Dublin. We work with organisations across the UK and Ireland on AWS and Azure, and our work is covered by ISO 27001 and Cyber Essentials Plus certification.
Tell us what Splunk does for you today
We will map it, tell you what is worth moving, and plan the migration so production stays visible the whole way. If we are not the right fit, we will say so.