Most SIEM migrations
move too much.
Carrying every rule, every source and every dashboard across is not a migration, it is a relocation. It reproduces the cost and the noise of the old platform inside the new one. The decisions about what to leave behind are the work.
The build,
not the subscription.
A project with a beginning and an end: design a Sentinel that fits your estate, migrate what deserves to come, and hand it over working. Separate from running it afterwards, which you may or may not want from us.
It covers both directions people arrive from. Some have no SIEM worth the name and need one designed and built. Others have a SIEM they are unhappy with, usually because it is priced per gigabyte and nobody enjoys querying it, and need to move without losing coverage on the way.
Microsoft funds a structured engagement for the second case, Sentinel Migrate and Modernize, and we deliver it. Funding is decided by Microsoft against their own eligibility rules rather than by us, so it is worth asking about early rather than assuming it.
- Workspace design, tenant and region decisions, and the retention tiers that follow from them.
- Data connectors, including the ones that do not exist yet for your estate.
- Analytics rules rebuilt against what you actually need to detect, not ported one for one.
- Playbooks, workbooks and the Content Hub solutions worth having.
- A parallel run, so nothing is switched off before its replacement is proven.
- Handover to your team, or to our SOC, or to both.
The hard decisions
are the subtractions.
Everybody scopes a migration by what has to come across. The projects that go badly are the ones that never decided what does not.
A legacy SIEM accumulates. Sources connected for a project that ended, rules written for a threat model nobody holds any more, dashboards built for a person who left. Port all of it and you have paid to move somebody else’s backlog onto a platform that charges by the gigabyte, and the first bill is the moment everyone discovers it.
So the assessment runs the other way round. Which sources feed a detection anybody acts on. Which rules have ever produced an investigation. What retention is genuinely required, against what is habit, and which of it can sit in a cheaper tier without breaking the obligation. Most estates we assess carry between a third and a half of their sources for no reason anybody can name today.
- Rules are rebuilt, not translated
- A rule written for a different correlation engine, ported literally, is noise with a new accent. The detection intent comes across; the implementation is written for Sentinel.
- Ingestion is the cost lever
- Sentinel prices on what you collect, so what you collect is an architectural decision rather than a default. Basic and archive tiers exist precisely so that not everything has to be hot.
- Parallel until proven
- Both platforms run until the new detections have fired on real traffic and been checked. No cutover creates a window where nobody is watching.
- The gaps come with you otherwise
- A migration is the one moment somebody looks at the whole estate. Identity logs missing from the old SIEM is the most common finding, and the cheapest time to fix it is now.
Assess, design, build,
run in parallel, cut over.
Five stages, and the fourth is the one that makes the difference between a migration and an outage.
-
01
Assess
What is connected today, what each source feeds, which rules have ever produced an investigation, and what retention is actually obliged. Produces the carry list and, more usefully, the drop list.
-
02
Design
Workspace, tenant and region, retention tiers, the connector set and the detection coverage you are aiming at. Costed for ingestion up front, because that is the number that surprises people.
-
03
Build
Connectors, analytics rules, playbooks and workbooks. Where a connector does not exist for something in your estate, we write it rather than declaring the source out of scope.
-
04
Run in parallel
Both platforms live while detections fire on real traffic and get validated against what the old SIEM saw. This is where a migration earns its confidence, and it is the stage most plans compress first.
-
05
Cut over and tune
Decommission the legacy platform once it is genuinely redundant, then tune against real volume. Handover to your team with the reasoning documented, or to our SOC.
Priced by the engagement,
after the assessment.
A migration cannot be quoted from a website, because the quote depends entirely on the drop list nobody has made yet.
- How many sources, and how many survive
- The carry list drives the work, not the inventory. An estate with 140 sources and 38 worth migrating is a smaller job than one with 60 that all matter.
- Whether connectors exist
- Most sources have a supported connector. The ones that do not are custom work, and they are usually the interesting sources rather than the trivial ones.
- How much detection is being rebuilt
- Rebuilding twelve rules that matter is quick. Recreating the intent behind two hundred, where the author has left and the documentation is the rule name, is not.
- How long the parallel run is
- Driven by how long it takes for the detections to see real activity, which is a property of your environment rather than of the project plan.
- Whether Microsoft funds it
- Sentinel Migrate and Modernize is a funded engagement, with eligibility decided by Microsoft. Worth establishing early, because it changes the shape of the commercials.
We assess first, and the assessment is worth having on its own: the drop list usually pays for it before anything is migrated.
Sentinel migration, answered.
How is this different from your managed Sentinel service?
This builds it. The managed service runs it afterwards, around the clock. They are bought separately and plenty of customers take one without the other, though most take the build first.
Can you migrate us from Splunk?
Yes, and from QRadar, ArcSight, LogRhythm and the rest. The platform matters less than the assessment: what feeds a detection somebody acts on, and what is being carried out of habit.
Will we lose detection coverage during the migration?
No, because both platforms run in parallel until the new detections have fired on real traffic and been validated. Nothing is decommissioned before its replacement is proven.
Does Microsoft really fund this?
Microsoft funds a structured migration engagement, Sentinel Migrate and Modernize, and we deliver it. Eligibility is Microsoft’s decision rather than ours, so it is worth asking early. You keep the findings either way.
What about our ingestion costs?
They are an architectural decision rather than a given. What you collect, which tier it lands in and how long it is kept are all designed rather than defaulted, and the drop list is usually where the saving is.
Do we have to take your SOC afterwards?
No. We hand over to your team with the configuration and the reasoning documented. If you would rather not operate it, the managed service is there, but the build does not assume it.
Send us the source list
and we will send back the drop list.
The assessment is worth having whether or not you migrate with us: most estates are carrying between a third and a half of their sources for no reason anybody can name today.