Most SOC platform migrations are declared successful on the day the old console gets switched off. The coverage gaps surface weeks later, usually by accident. Someone goes looking for an alert that should have fired, finds nothing, and then finds out that the log source behind it stopped arriving during the cutover and nobody was watching that particular pipe.
That gap is rarely caused by carelessness. It happens because migration projects track the things that are easy to count, which are rules ported, connectors built and dashboards rebuilt, while coverage is a property of three things at once and only one of them appears on a project plan.
This is a runbook for the other two. It covers what to measure before you move anything, the ways coverage disappears without leaving a signal, a phased sequence with exit criteria you can hold a vendor and your own team to, and the verification pass that catches what the cutover missed. It’s about moving the detection stack. If what you’re replacing is an AI SOC platform sitting on top of that stack, the exercise is different and Radiant Security Alternatives covers it.
Key Insights: What You Need to Know About SOC Platform Migration
- SOC platform migration puts detection coverage at risk in three places at once: telemetry has to keep arriving, logic has to fire correctly on it, and someone has to be watching who knows what to do. Most migration plans only track the first.
- A SIEM migration is the most common form of this cutover, and the hardest part is the tuning rather than the rule text. Exclusions, thresholds and allowlists rarely travel with a converted rule, and the reasons behind them usually exist only in analysts’ memories and old tickets.
- The SOC migration checklist starts with a baseline: detections mapped to MITRE ATT&CK techniques, the log sources behind each detection, thirty days of volume normals, the tuning with its reasons, owners and known blind spots, all captured before the new platform arrives.
- Coverage disappears in six recognizable ways, from a source that never arrived to automation keyed to the old alert format, and each failure mode has a symptom you can monitor for on purpose rather than discover by accident.
- Detection engineering owns the parallel run: every alert that fired on only one platform gets a named owner and a written disposition before the phase closes. The alerts both platforms agreed on are the least informative result.
- A SOC platform migration is finished at 90 days, well after cutover. Fire rates checked against the baseline at 30 days, the technique map re-run at 60, and historical search tested against real questions at 90, each pass with the same named owner.
Coverage Is Three Layers, and a Migration Only Protects One
Ask a team what its detection coverage is and you will usually get a number of rules. Rule count is the least informative thing you can know about coverage, because coverage needs three separate conditions to hold at the same time.
Telemetry has to arrive. The log source is onboarded, it is parsing into the fields the logic expects, the volume looks like yesterday’s volume and the retention window is long enough for the lookback the detection performs. A rule watching a source that stopped shipping doesn’t fail. It just never fires, which looks identical to a quiet week.
Logic has to fire correctly on it. The detection exists in the new platform, it is enabled, and it is tuned to your environment rather than to the vendor’s defaults. Porting the text of a rule isn’t porting the detection, because the accumulated tuning is the part that made it usable here.
Someone has to be watching, and know what to do. The output routes to a queue a human or a platform reads, with an owner, a documented next step and a severity that means what it meant before. A detection that fires into a channel nobody opens is coverage on paper only.
A migration threatens all three and is planned around the first. That is the whole problem in one sentence, and the runbook below is built to close it.
Baseline Before You Touch Anything
You can’t prove coverage came back if you never wrote down what it was. This baseline is the core of any SOC migration checklist worth the name. It’s also the step most often skipped under schedule pressure, and the one that makes every later argument decidable, so do it before the new platform arrives, not during the overlap.
| Capture this | How | Why it disappears otherwise |
|---|---|---|
| Detections mapped to technique | Map each live detection to the MITRE ATT&CK technique it covers, not to its rule name | Rule names rarely survive a platform change and techniques do, so a technique map is the comparison that still holds on both sides |
| The log sources behind each detection | For each detection, list the sources it reads and the retention window it needs | The most common silent gap is a source that never got onboarded on the new side |
| Baseline volumes and firing rates | Thirty days of events per source per day, and alerts per detection per week | Without a normal, you cannot tell a fixed false positive from a broken pipeline |
| The tuning, and the reason for it | The exclusions, thresholds and allowlists on each detection, each with the case that caused it | This is institutional knowledge, it lives in ticket comments, and it is what teams rebuild from scratch and get wrong |
| Owner and next step | Who owns the detection, where it routes, what the person who picks it up is expected to do | Ownership is the layer that vanishes without a signal when a queue is rebuilt |
| Known blind spots | The coverage you already know you do not have, written down | Otherwise a pre-existing gap gets discovered after cutover and blamed on the migration |
Two of these rows carry most of the value. Technique mapping is what lets you compare two platforms honestly, and the tuning inventory is what stops your new deployment from reproducing three years of false positives in its first month.
Six Ways Coverage Disappears, and the Tell for Each
None of these announce themselves. Each one has a symptom you can look for on purpose.
A source that never arrived. The connector was built, credentials expired in week two, and the pipeline has been empty since. The tell is a source whose daily volume goes flat rather than to zero, or goes to zero on a day nobody was looking. Alert on absence of data per source, not just on errors.
The rule ported, the schema did not. The rule arrived intact and now reads a field the new platform names differently or normalizes differently. Two outcomes, both bad: it never fires, or it fires on everything. The tell for the first is a detection with zero hits since cutover that used to have a weekly rhythm. The second announces itself.
Tuning rebuilt from memory. The exclusions weren’t documented, so the new deployment starts from vendor defaults. The queue floods, the team triages by muting, and three weeks later a genuine detection is muted alongside the noise. Watch for a spike in alert volume followed by a fall that nobody explicitly engineered.
The detection that was never a detection. Someone’s saved search, a scheduled report, a dashboard panel that a senior analyst checked every morning. It covered something real and it was never in the rule inventory, so it was never migrated. You will hear it as an analyst saying “I used to just look at” in the weeks after cutover. Ask the question directly during the baseline.
A shorter lookback than the rule needs. The new platform has a different hot window, and a detection that looked back thirty days now looks back seven. It still fires, against a much shorter window of data. This one is invisible in every count you can run, which is why the baseline records the lookback each detection needs.
Automation that was keyed to the old shape. Downstream workflows matched on the old alert name, severity string or ID format. They keep running and match nothing, with no error to show for it. The tell is a workflow whose execution count drops without its trigger volume dropping.
The Cutover Sequence, With Exit Criteria
Phases exist to stop a SOC platform migration from advancing on optimism. Each one below has a gate, and the gate is the point: no phase is finished because the calendar says so.
| Phase | What happens | You may move on when |
|---|---|---|
| 0. Baseline | Capture the six inventory items above, freeze them, and agree who signs off on coverage | The technique map and the tuning inventory exist as artifacts, not as tribal knowledge |
| 1. Dual ingest | Both platforms receive the same telemetry. No detections run on the new side yet | Volume per source matches between platforms within an agreed tolerance, for a full week including a weekend |
| 2. Parallel detection | Detections run on both. The old platform still owns the queue | Every technique in the baseline map has a detection on the new platform that has been seen to fire, on live traffic or on a replayed event, and every disagreement has a named owner |
| 3. Queue shift | The new platform owns the queue. The old platform still runs, watched, not worked | A full on-call rotation passes with no detection reintroduced from the old side |
| 4. Decommission | The old platform is switched off, its data exported, its retention obligations transferred | Historical search has been tested against the exported data by someone who needed it, not by the person who exported it |
| 5. Verification | The 30, 60 and 90 day passes below | Each pass closes with a named owner on every open item |
Phase 2 is where migrations are won or lost, and it’s the phase most often compressed when the schedule slips. Compressing it moves the risk rather than removing it, and moves it to the period when the old platform is gone.
Read the Disagreements, Do Not Count Them
During parallel detection you will get three outcomes per alert: both platforms fired, only the old one fired, only the new one fired. Teams under pressure count these and report a percentage. The percentage is nearly meaningless, and the third bucket is where the useful information is.
Only the old platform fired means either a real gap, or a detection whose tuning did not travel. Both need an owner and neither is a rounding error.
Only the new platform fired is more interesting than it looks. Sometimes it is a false positive that needs the same tuning the old rule got years ago. Sometimes it is something the old stack was genuinely missing, in which case you have just found the argument for the whole project, and it belongs in the write-up rather than in a spreadsheet cell.
Both fired is the least informative outcome and the one that gets celebrated. Sample it, don’t count it. The interesting question is whether the two verdicts agreed about what the alert meant, not whether both produced one.
Set a rule at the start of the phase: every alert in one of the single-platform buckets gets a named owner and a written disposition before the phase closes. That single rule is what turns a parallel run into evidence.
The Tuning Problem, Which Is a People Problem
The hardest thing to migrate is the reason a rule has an exception, which normally exists as a memory in one engineer’s head and a two-line comment on a closed ticket from 2024.
There’s no clever way around this, but there are three things that work. First, mine the ticket history rather than the rule set: search closed cases for the exclusions and read why they were added, and do it during the baseline while there is still time. Your detection engineering team will recognize this as the audit they have been postponing. Second, treat every tuning decision you cannot explain as a decision to re-make rather than to copy, because an exclusion nobody can justify is either obsolete or a blind spot, and both deserve a look. Third, write the reason into the new platform as you go, in whatever field it offers, so the next migration is cheaper than this one.
Expect the exercise to shrink the estate. Some exclusions turn out to be protecting against a system that was decommissioned two years ago, and some detections haven’t fired since a product was retired. Give the project a delete column alongside the migrate column, with the same owner and the same sign-off.
Verify at 30, 60 and 90 Days
A SOC platform migration’s risk window doesn’t close at cutover. Run three passes, each shorter than the last.
At 30 days, compare fire rates per detection against the baseline. Anything at zero that used to have a rhythm gets investigated as a defect until proven otherwise. Check volume per source against the baseline normals. Then walk the list of downstream workflows: each one has either fired since cutover, or somebody has triggered it deliberately to prove it still runs.
At 60 days, re-run the technique map against what is live now and look for techniques that were covered before and are not covered today. Review the alerts your team muted or downgraded in the first weeks, because that is where a genuine detection most often gets buried.
At 90 days, test historical search: take three real questions from the last quarter and answer them using only the new platform and the exported archive. If it takes noticeably longer than it used to, find out which part is slow: the retention window, the export format, the query language or the fact that nobody has practiced on the new tool. All four are cheaper to fix now than during an incident.
Put all three in the calendar before the cutover, with the same owner. A verification pass that depends on somebody remembering is not a control.
A Note on Where We Sit
We build CognitiveSOC™, an AI SOC platform, so it’s worth saying that a platform migration is your project, on your timetable, and nothing above changes if you never speak to us.
One thing we would push you on, because it is the step that pays later. Exclusions are cheap to list and expensive to justify after the fact. Write the reason down while somebody still remembers it, in the same pass that captures the exclusion, and your next migration is the short one.
Frequently Asked Questions
How Long Does a SOC Platform Migration Take?
In a SOC platform migration the connector work can run long and often does, but it’s the parallel detection phase that usually sets the floor. Both sets of detections have to run side by side long enough to see a real month, including the end-of-month and end-of-quarter patterns that generate their own noise. Teams that compress this phase are the ones that find gaps after the old platform is gone.
What Is a Detection Coverage Gap?
A detection coverage gap is any point where a threat behavior you believe you detect goes undetected. It has three causes and only one is about rules: the telemetry never arrived, the logic did not fire correctly on it, or the output went somewhere nobody acts on. A migration can create all three at once, which is why coverage should be measured on techniques rather than on the number of enabled detections.
Can We Migrate Detections Automatically Between Platforms?
In a SIEM migration the rule text often converts, and conversion tooling is genuinely useful for that mechanical part. Two things need a human afterward: the tuning, meaning the exclusions, thresholds and allowlists that made the detection usable here, and the field mappings, since a converter can only map fields it knows about. The check is per detection, not per batch. Open the converted rule next to its baseline entry, confirm every exclusion is present and every field it reads exists on the new side, then mark it migrated. A detection nobody has opened is still only converted.
Do We Have to Run Both Platforms in Parallel?
It’s how a claim about coverage becomes a measurement, and it’s usually the reason two contracts run at the same time for a while. If that isn’t affordable at full scope, narrow the scope rather than skipping the phase: pick the technique coverage you would least like to lose and run those in parallel. Then list the detections that crossed untested and put the list in front of whoever signs off on the migration. Somebody should be accepting that risk on purpose, with their name on it.
What Happens to Our Historical Data?
Decide this before the cutover, not after, because it’s a compliance question as well as an investigative one. Establish what the retention obligation is, where the archive will live, in what format, and who can search it. Then test a real historical search against the archive before the old platform is switched off, with somebody who needs the answer.
How Do We Know the Migration Is Finished?
When the technique map from your baseline is covered on the new platform, every detection that stopped firing has been explained rather than assumed, historical search has been tested, and the 90 day verification pass has closed. The day the old console gets switched off is a milestone in that sequence, not the end of it.
Should We Change Detection Logic During a SOC Platform Migration?
Not at the same time. Change the platform or change the logic, and do the second one afterward, because every rule you improve during the move becomes a variable in your parallel comparison and you lose the ability to attribute a difference. Keep a list of the improvements you want, and start on it once the verification passes have closed.