The Journey from Old Sentinel to New Sentinel: A Story About One Rule at a Time

1. Title + Hook

Imagine you’re not “migrating rules” – you’re moving an entire family to a new city.

• The KQL is just the person.
• The data sources, watchlists, playbooks, MITRE mapping, entity mappings – that’s the job, school, bank, electricity.

Move only the person and forget the rest? Their life breaks.

This story is about doing the move properly.

2. Why It’s Needed (Context)

In the company, people say:

“Just move the rules to the new Sentinel.”

But you know the truth:

• New Sentinel uses different agents (AMA), different schemas, maybe ASIM parsers.
• Some rules never fire after the move.
• Some automations create chaos: duplicate tickets, wrong emails, noisy incidents.

So you decide:
“This won’t be a copy-paste job. This will be a guided migration journey.”

And you have a junior colleague who will walk this path with you. Your job: tell them the story in a way they can follow.

3. Core Concepts Explained Simply

Let’s explain the core ideas as if you’re telling them over coffee.

a) Rule Inventory

• Technical definition: A list of every analytic rule, with its type (Scheduled, NRT, ML, Fusion, UEBA), data sources, mappings, playbooks, etc.
• Story version:
  “Before we move houses, we write down everything we own. Not just ‘we have a TV’ – but the cables, remote, wall mount. Same with rules: not just the KQL, but what it depends on.”
• Technical example:
  A spreadsheet with columns: RuleName, Type, TablesUsed, MITRE, Entities, Watchlists, Playbooks, Suppression, Grouping, LastTriggered.

b) Data Dependency

• Technical definition: Making sure the same logs and schemas exist in the new Sentinel.
• Story version:
  “If we move to a new city, we need water, electricity, internet. No point carrying a washing machine if there’s no plumbing.”
• Technical example:
  Old rule uses SecurityEvent. In the new workspace, logs are coming via AMA, maybe with EventData inside JSON, or ASIM parser is needed. You check:
  • Does SecurityEvent exist?
  • Is ASIM parser deployed?
  • Are events coming in now, not just last week?

c) KQL Logic

• Technical definition: Query runs correctly, fields exist, watchlists are correct, no deprecated functions.
• Story version:
  “We test the recipe in the new kitchen. Same ingredients? Same oven? Same timing?”
• Technical example:
  You run the old KQL in the new Log Analytics workspace. It fails because a column is renamed. You fix it. Only then you create the new rule.

d) Rule Behavior

• Technical definition: How often it fires, how many alerts, which entities, which severity.
• Story version:
  “In the old city, our AC turned on at 7 PM. In the new city, we want the same comfort. Not freezing at 2 AM or dead silence.”
• Technical example:
  Old rule: 10–15 alerts/day, severity High, grouped by account.
  New rule: you compare and check if behavior is similar.

e) Automation (Playbooks)

• Technical definition: The playbook or Logic App that runs when the rule fires.
• Story version:
  “When the doorbell rings, who answers? Do we still want the same person answering in the new house? And are they sober?”
• Technical example:
  Old rule calls a playbook that creates a ticket in ServiceNow. In the new environment, the connection reference is different. You reconnect it, but keep it disabled until you’re happy with alerts.

f) UCMR – Use-Case Migration Record

• Technical definition: A per-rule document describing how it moved from old to new.
• Story version:
  “It’s like keeping a folder per family member: where they lived before, where they live now, what changed, and proof that they’re okay.”
• Technical example:
  A record (in a ticket, wiki page, etc.) that stores: old name, new name, old KQL, new KQL, data sources, MITRE, entity mappings, test results, go-live date, owner.

4. Real-World Case Study

Failure Story – “The Silent Rule”

You migrate a custom lateral movement rule.

• You copy the KQL.
• You recreate the rule in the new Sentinel.
• You enable it.

Then… nothing. No alert for days.

Later you discover:

• The new workspace uses AMA.
• The table name changed, or some fields moved.
• The KQL was still pointing to old fields.

Result: the rule was enabled but blind.

Lesson:
Always check data + run the KQL in the new workspace before enabling the rule.

Success Story – “The Measured Move”

You decide to do it right.

For each rule:

• You test the KQL in the new workspace.
• You fix fields and schemas.
• You keep the new rule disabled or Informational severity.
• You run it in parallel with the old environment for 1–2 days.
• You compare:
  • Are we getting similar number of alerts?
  • Are the entities (accounts, IPs, hosts) the same?
  • Are playbooks behaving correctly?

Only when you are happy, you:

• Turn on real severity (e.g. High).
• Turn on automation.

Result:
No shocks. No surprises. The new Sentinel feels like the old one—but cleaner, with fewer false positives.

5. Action Framework — Prevent → Detect → Respond

Prevent (before touching anything)

• Take a full inventory of rules.
• Check that required data sources are flowing to the new Sentinel.
• Set your naming rules and severity rules.
• Prepare the UCMR template.

Detect (during migration)

• For native/content hub rules: reinstall them in the new Sentinel. Don’t copy them by hand.
• For custom rules:
  • Copy the KQL.
  • Run the KQL in the new workspace.
  • Fix any broken bits (tables, columns, watchlists).
  • Create the rule disabled or with non-impactful severity.

Respond (after migration)

• Run both old and new rules for some time.
• Compare:
  • Are we missing alerts?
  • Are we getting too many?
• Only then:
  • Turn on real severity.
  • Enable playbooks.
• Keep UCMRs updated as your proof and history.

Small visual for your colleague:

[Old Rule] 
   ↓ Analyze
[Data OK? KQL OK?]
   ↓ Rebuild
[New Rule (Disabled)]
   ↓ Test 24–48h
[Compare with Old]
   ↓ If OK
[Enable Alerts → Enable Automation]
   ↓
[Close UCMR]

6. Key Differences to Keep in Mind

1. Reinstall vs Copy
   • Native rules → reinstall from Content Hub.
   • Custom rules → rebuild manually.
     Example: Don’t copy a built-in “Impossible travel” rule. Install its solution again.
2. Data First, Logic Second
   • No data = no detection, no matter how smart the query.
     Example: Your rule looks perfect, but the underlying table isn’t even connected.
3. Staging Before Production
   • Always run in “staging mode” (disabled alerts or low severity) before going live.
     Example: 1–2 days of testing can save you thousands of useless tickets.
4. Automation as Last Step
   • First get good alerts, then attach playbooks.
     Example: You don’t want a broken rule spamming your SOAR and ticketing system.
5. UCMR as Your Shield
   • Every rule should have its migration story written.
     Example: When someone asks “Why did this change?”, you have a one-page answer.

7. Summary Table

8. What’s Next

This story was about moving the rules safely.

The next story could be:
“How Entity Mapping Makes Analysts’ Lives Easier: Turning Raw Logs into People, Hosts, and IPs They Can Trust.”

That’s where you explain how a small change in mapping can turn chaos into clarity on the Sentinel incident screen.

9. 🌞 The Last Sun Rays…

In the end, your colleague isn’t “copying KQL.”
They are:

• Listing everything you own (inventory).
• Making sure the new house has water and power (data).
• Testing the oven before cooking for guests (KQL tests).
• Letting the family settle before inviting the whole neighborhood (staging, then automation).
• Writing down what changed, so nobody is lost (UCMR).

That’s how a messy migration becomes a calm, controlled journey.

The reflection question for them:

“When you move your first rule, what will you check first in the new Sentinel workspace: the data, the KQL, or the automation—and why?”

Related reading: Explore our related CISSP study guide

Sentinel migration planning and common mistakes are covered in Microsoft Sentinel Migration Mistakes: How NOT to Migrate to Sentinel. The analytics rules being migrated can be audited using the process in How to Audit Microsoft Sentinel Analytics Rules with Python. For Sentinel detection design best practices, see Microsoft Sentinel Detection Use Case Mistakes: How NOT to Design Detections. The overall Sentinel architecture context is in Microsoft Sentinel Architecture Mistakes: How NOT to Design Sentinel.

For official resources, visit Microsoft Sentinel Documentation.

Related reading: Microsoft Sentinel Complete Operations Guide — the central hub for all Sentinel content on SunExplains.

Surya

By profession, a CloudSecurity Consultant; by passion, a storyteller. Through SunExplains, I explain security in simple, relatable terms — connecting technology, trust, and everyday life.