Pre-migration prerequisites
Before touching a single connector, you need a signed-off telemetry inventory, an approved detection catalogue snapshot, and a compliance sign-off on retention continuity. Without these three artefacts, any migration date you set is fictional.
Assign a migration owner with P1 authority — someone who can freeze the legacy rule catalogue, approve connector PRs, and escalate retention disputes to legal without a meeting chain. Migrations that need committee approval for every decision miss their dates.
Define your rollback gate criteria upfront: if X coverage gaps appear in dual-run, you roll back to shadow. If median MTTV exceeds Y during dual-run, you hold the phase. Write the numbers before the work starts.
- Telemetry inventory signed off by SecOps lead
- Detection catalogue snapshot committed to git with hash
- Compliance retention sign-off from legal
- Migration owner named with P1 authority
- Rollback gate criteria documented and agreed
Phase 1 — connector deployment (weeks 1–2)
Deploy connectors in priority order: identity providers first (Okta, Entra ID, Google Workspace), then cloud control planes (AWS CloudTrail, Azure Activity Log, GCP Audit Logs), then endpoint telemetry, then SaaS applications. Identity and cloud control plane coverage is what powers the entity graph — everything else builds on top.
Each connector should be validated against a known-good event before you move to the next. Pick one event you can reproduce (an Okta login, an S3 GetObject, a GCP IAM change) and confirm it appears in the graph with correct OCSF fields before marking the connector ready.
Track connector status in a shared doc: source name, owner, deployed date, validation event, and volume/day. This doc is your migration dashboard for the next eight weeks.
# Validate connector by querying for a known event
curl -s -X POST https://app.manysignal.io/api/v1/graph/query \
-H "Authorization: Bearer $MS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"source": "aws_cloudtrail_mgmt",
"class_uid": 3002,
"actor_user": "terraform@ci.acme.com",
"window": "1h"
}' | jq '.total_events'Phase 2 — rule translation (weeks 2–4)
Export the legacy rule catalogue. Score each rule: TP count (last 12 months), FP count, MITRE technique covered, and active/inactive status. Rules with zero TPs and high FPs are dropped. Rules covering unique MITRE techniques with no equivalent get translated first.
Translate rules in three passes: streaming detections (single-event thresholds) first, then correlation detections (multi-event sequences), then behavioural detections (per-entity baseline anomalies). Behavioural detections often replace entire families of noisy threshold rules.
Every translated detection gets a backtest run against 30 days of production data before it enters staging. A detection that would have fired 200 times in 30 days with zero TPs is not ready for production.
Phase 3 — shadow mode (weeks 4–8)
Shadow mode means ManySignal fires detections and creates cases, but no external notifications or response actions leave the platform. The legacy SIEM remains the source of truth for analyst queues. Run shadow for at least 30 days — longer if your detection catalogue is large.
During shadow, compare every ManySignal case against the legacy alert log. For every legacy alert that has no ManySignal case, open a coverage gap ticket. For every ManySignal case that has no legacy alert, classify it as net-new coverage or noise.
The shadow exit gate: less than 5% coverage gaps vs legacy, and net-new ManySignal cases have been reviewed and classified. Do not advance to dual-run until the gate clears.
Phase 4 — dual-run and cutover (weeks 8–12)
Dual-run flips ManySignal to authoritative for triage while legacy remains ingesting. Analysts work ManySignal cases. Legacy alerts are monitored for anything that doesn't surface in ManySignal. Duration: 30 days minimum.
Dual-run exit gate: two consecutive weeks with zero unmatched legacy alerts, median MTTV within 20% of target, and autonomous verdict rate above 80%. When the gate clears, schedule legacy sunset.
Legacy sunset is a hard cutover of ingestion and alerting. Keep legacy in read-only mode for six months minimum to support historical lookups during audits and incident scope reviews.
Post-migration: first 90 days of steady-state
The first 90 days after legacy sunset are when the operational model cements. Run a weekly metrics review: autonomous verdict rate, MTTV by severity, TP:FP by detection domain, cases opened and closed, cost per verdict.
Use the first 90 days to introduce detection engineering practices that were impractical in the legacy environment: backtesting new rules before promotion, scheduled coverage gap analysis against MITRE ATT&CK, and monthly autonomous threshold calibration reviews.
Key takeaways
- Three artefacts gate the start: telemetry inventory, detection snapshot, compliance sign-off.
- Deploy connectors in priority order: identity, cloud control plane, endpoint, SaaS.
- Validate each connector with a reproducible known-good event before proceeding.
- Shadow mode minimum is 30 days — gate exit on less than 5% coverage gaps.
- Dual-run gate: two consecutive clean weeks, MTTV within target, 80%+ autonomous rate.
- Keep legacy read-only for six months post-sunset for historical lookups.