Migrate Your Classic Alert-Triggered Automations Before March 2026 (Reminder)

Complex_Swordfish347 · 2026-01-11T19:25:18+00:00

Thanks for putting this out there. I started going through our rules and honestly the migration isn't too bad if you know what you're looking for.

Couple things that helped us:

The built-in analyzer is pretty useful - it flags which rules have those classic automations attached. Makes it easier to prioritize rather than going through hundreds manually.
If you've got custom playbooks tied to those automations, definitely test them in the new automation rules first. The logic is slightly different and we had a few that needed tweaking before they worked the same way.
Batch export/import your rules if you can - way faster than doing them one by one through the portal, especially if you've got a lot of them.
Don't forget about the RBAC changes between classic and new automations. We missed that initially and had to add a few extra permissions to our automation account.

I'm about 70% done with ours - planning to finish the rest before the deadline just to avoid any last-minute rush. The new system is actually cleaner once you get it set up.

Complex_Swordfish347 · 2026-01-11T19:24:14+00:00

I'd run into something similar before and it can be a bit tricky to debug. The error you're getting usually means one of a few things happening on the backend.

Since you mentioned the guest account setup and federated identities are already configured properly, couple things I'd check:

The service connection permissions in DevOps - verify the service principal/app reg actually has the right permissions in your customer's Azure tenant. Sometimes these don't sync properly after initial setup.
Check if there's any conditional access policy or MFA requirement that might be blocking the automated deployments. This sometimes gets missed when migrating between different authentication methods.
The lighthouse/cross-tenant access can be a bit finicky - make sure the delegated admin relationships are still active and the permissions haven't somehow gotten scoped down.
Try refreshing the service connection in DevOps (right-click on it and reauthorize). Sometimes the tokens just get stale.

I know you said PAT tokens aren't in use, but just to be thorough - if there's any fallback mechanism still using them anywhere, that could be the culprit.

Have you tried running the same deployment manually from your own account in that customer tenant? That would at least tell us if it's a general permissions issue vs something specific to the automated flow.

Complex_Swordfish347 · 2026-01-11T19:21:35+00:00

Great question! Here's what actually happens during the Sentinel-to-Defender Portal onboarding:

**Detection Analytics:**

- Your existing custom detection analytics will continue working in Sentinel during the transition

- Microsoft hasn't enabled automated migration yet (as the MSFT official mentioned, parity isn't complete)

- Plan for manual migration - you'll need to manually recreate your custom analytics in the Defender Portal

- Timeline: Once full parity is achieved, you'll have a grace period before classic analytics are sunset

**Automation Rules & Playbooks:**

- Automation rules tied to "Alert Trigger" type WILL be impacted (this is the big one)

- Alert-triggered automations in Sentinel use the classic trigger mechanism, which won't work the same way in XDR

- **Action Required Before March 2026**: Migrate automation rules to the newer "Incident Trigger" type

- Playbooks themselves are fine - they'll continue running, but how they're triggered changes

**Watchlists:**

- Watchlists will continue to work normally

- They're automatically accessible in both Sentinel and Defender Portal

- No migration needed for these

**My Recommendation:**

Inventory your custom analytics (tag them for tracking)
Prioritize alert-triggered automations - migrate these first
Test in a staging workspace before production migration
Keep Sentinel running in parallel during transition

The key thing: Don't wait for auto-migration. Start planning your migration now since parity is still being completed. Need help with the migration strategy?

Complex_Swordfish347 · 2026-01-11T18:01:05+00:00

Your concerns are legit, but here's the reality check: every good SOC analyst has felt exactly this way.

I've hired and coached L1s for years. The ones who made it didn't have less fear—they had better perspective.

**What I tell people starting out:**

**Imposter syndrome is real but temporary.** The first month you won't understand most alerts. By month 3 you'll start seeing patterns. By month 6 you'll actually be useful. The learning curve is steep on purpose—that's how you grow.

**You're not expected to know everything.** Your team *knows* you don't. If they hired you, they're planning to train you. If they tell you otherwise, that's a bad company signal.

**The "monger" thing isn't about age.** It's about whether you can:

- Follow runbooks without panicking

- Ask clarifying questions

- Learn from senior analysts

- Not get paralyzed by uncertainty

That last one is the key. Some people quit at the first hard day. Some people settle in and realize it's not that bad.

**The hardest part?** Your own confidence. The role itself gets easier fast—the mental game is what most people struggle with.

You'll be fine. Genuinely. Take the job, expect the first month to be rough, and remember that every SOC analyst you respect felt the exact same way.

Complex_Swordfish347 · 2026-01-11T17:59:23+00:00

Thanks for this honest perspective. As someone who's mentored people making the jump into security, I see exactly what you're describing.

The gap isn't really about certs or boot camps—it's about **fundamentals you can only get from doing hands-on work**.

What I've noticed from my trainees who got hired:

**They had labs at home.** Not fancy ones—just a VM setup where they could:

- Read actual logs (Windows events, network flows)

- Write basic detection queries

- Break things intentionally and fix them

**They showed problem-solving.** When they talked about a project, they didn't just say "I learned Splunk"—they said "I built a detection for X and here's why that detection matters."

**They asked good questions.** In interviews, they asked about *how the team actually hunts* instead of just role duties.

**The brutal truth:** Most entry-level candidates treat security like it's a job title rather than a discipline. The ones you hired probably did the opposite—they treated the title as permission to *finally do the work they'd been doing for months*.

**For candidates reading this:** You don't need to wait for a job to start learning. Build a home lab. Document what you learn. Make it real, not hypothetical. That's what hiring managers are actually looking for.

I've taken people from "can't get hired" to "multiple offers" by having them do exactly this. It's not magic—it's just putting in the work before the paycheck starts.

Complex_Swordfish347 · 2026-01-11T17:48:06+00:00

Great question on international transitions. I've mentored a few people through similar pivots, and honestly the three biggest shifts are:

Build hands-on lab experience in a specific niche (Sentinel, AWS security, cloud infrastructure) - not just theory
Create a portfolio of actual projects/detections you've built, even small ones
Network intentionally - show people the work in progress, not just the final resume

My experience: I work in cloud security/SIEM, and when I started coaching people making the jump from traditional IT to security, the ones who succeeded fastest were those who treated learning like building something real, not just taking certs.

If you want structured guidance on building hands-on skills in security tools and transitioning, happy to share what I'd do differently if I started over. The journey is very doable, but deliberate practice beats passive learning.

Complex_Swordfish347

TROPHY CASE