From 4h to 12m: a Sentinel migration write-up

Every SIEM migration is sold on licence cost and lives or dies on trust. The board signs off because the renewal quote doubled; the SOC only relaxes once it believes the new platform sees everything the old one did. Get the sequencing wrong and you spend the first quarter explaining why a detection “went quiet” — when in fact it was never wired up.

This is the write-up of one such move: a mid-market manufacturer with a legacy on-premises SIEM, eleven sites, and a two-analyst rota that had stopped trusting its own alert queue. Names are abstracted, but the shape and the numbers are real.

The starting point

The legacy platform had accreted roughly 1,100 correlation rules over six years, most of them inherited, undocumented, or duplicated. Mean time to acknowledge a genuine alert sat at about four hours — not because analysts were slow, but because the signal was buried. On a representative week, the queue carried more false positives than true ones by a wide margin.

The brief was deliberately narrow: move to Microsoft Sentinel, lose nothing that mattered, and come out the other side with a queue the analysts would actually work.

What we kept, what we replaced

The temptation on any migration is to lift-and-shift the rule set. We did the opposite: we treated the 1,100 rules as a backlog to justify, not a inventory to port.

• Kept: the high-value detections with a clear owner and a real incident history behind them — about a fifth of the estate.
• Replaced: bespoke correlation logic with Sentinel’s analytics rules and the built-in Microsoft security connectors, which covered a large slice of the old custom work out of the box.
• Retired: the long tail of duplicated and never-fired rules, documented and signed off so no one could later claim a capability had vanished silently.

A migration is not finished when the data flows. It is finished when the analyst on shift trusts the queue enough to act without double-checking the old console.

The 90 days, in three phases

Weeks 1–4 — parallel run

Both platforms ran side by side. Every alert raised in the legacy SIEM was checked against Sentinel, and every gap was logged and closed before anything was switched off. This is the unglamorous work that earns the right to decommission.

Weeks 5–9 — tune and suppress

With coverage proven, the focus moved to noise. Structured suppression, entity enrichment, and threshold tuning took the false-positive rate down by roughly 60% inside the first month — the single change the analysts felt most.

Weeks 10–13 — cut over and decommission

The legacy platform moved to read-only, then to archive. The rota retrained on a queue a quarter of the previous size, and the renewal that started the whole conversation was allowed to lapse.

The analyst rota, after

The headline number is the four-hours-to-twelve-minutes shift in acknowledgement time, but the change the team talks about is quieter: shifts now end with the queue cleared. Escalation paths are explicit, handover is a two-minute conversation rather than a tour of unexplained alerts, and the 2am page is rare enough to mean something when it fires.

What we would tell you to do differently

• Budget the parallel run properly. The four weeks of overlap is where the “we lost a detection” risk actually gets retired. Cutting it short to save licence overlap is a false economy.
• Justify every ported rule. If no one can name the incident a rule exists to catch, it is noise — and you are about to pay to carry that noise into a new platform.
• Tune before you celebrate. Coverage proves you are safe; tuning is what makes the platform usable. They are different jobs and the second one is where the value is.

None of this is exotic. It is the discipline of proving coverage before chasing noise, and refusing to treat a rule set as sacred just because it is large. The platform helped — but the result came from the sequence, not the logo.

Illustrative engagement summary — figures are representative of a real programme; client named under NDA on request.