SolarWinds to Sentinel: 1:1 Migration

The Problem

Leadership decided not to renew the on-premises SolarWinds SIEM because of its cost. My research showed that Microsoft Sentinel could cover the same setup for roughly 63-70% lower annual cost. The existing Sentinel workspace ingested only Entra sign-in logs, so moving the full SolarWinds setup meant bringing over every log source and every rule without losing coverage.

What I Built

• An inventory of all SolarWinds rules and the systems sending data to the legacy SIEM
• Security log collection from domain controllers and other critical servers (about 6 servers) using Azure Arc, the Azure Monitor Agent (AMA), and Data Collection Rules (DCRs)
• A hardened Linux server that forwards switch and firewall syslog into Sentinel through the same Arc/AMA path
• Tuned Entra log configuration for the workspace that already existed
• About 30 SolarWinds rules rebuilt 1:1 as custom KQL analytic rules, with Logic Apps for email alerts

How It Works

1. Inventory: I documented each SolarWinds rule and each system sending it data. That list became the migration plan and the checklist for parity.
2. Ingestion: Domain controllers and other critical servers were onboarded to Azure Arc. AMA collects their security logs, and DCRs control what goes to Sentinel. Switches and firewalls send syslog to a hardened Linux server, which forwards it to Sentinel through the same Arc/AMA path.
3. Rule rebuild: I recreated each SolarWinds rule as a custom KQL analytic rule, and Logic Apps send the email alerts. The rules map 1:1 to the originals so auditors can trace each legacy rule to its replacement.
4. Parallel run: SolarWinds and Sentinel ran side by side for about a month. Afterward, the legacy instance stayed in place temporarily as a fallback to catch any undocumented rules.

Impact