Data Connector Migration: Splunk to Sentinel¶

Status: Authored 2026-04-30 Audience: Security Engineers, SOC Infrastructure Teams, Platform Engineers Purpose: Guide for migrating Splunk data inputs, forwarders, and apps to Microsoft Sentinel data connectors and Azure Monitor Agent

1. Data collection architecture comparison¶

Splunk data collection¶

Data Sources ──> Forwarders (UF/HF) ──> Indexers ──> Search Heads
                      │
              syslog/CEF inputs
              scripted inputs
              modular inputs
              HTTP Event Collector (HEC)
              DB Connect

Sentinel data collection¶

Data Sources ──> Data Connectors ──> Log Analytics Workspace ──> Sentinel
                      │
              Azure Monitor Agent (AMA)
              Syslog/CEF via AMA
              Data Collection API
              Content Hub solutions
              Native Microsoft connectors
              Logic App connectors

2. Forwarder to Azure Monitor Agent migration¶

Replacing Universal Forwarders¶

Azure Monitor Agent deployment¶

# Install AMA via Azure Arc on Windows servers
# First, onboard server to Azure Arc
azcmagent connect `
    --resource-group "rg-sentinel-prod" `
    --tenant-id "<tenant-id>" `
    --subscription-id "<subscription-id>" `
    --location "usgovvirginia"

# Then deploy AMA via Azure Policy or manually
az connectedmachine extension create `
    --resource-group "rg-sentinel-prod" `
    --machine-name "server01" `
    --name "AzureMonitorWindowsAgent" `
    --publisher "Microsoft.Azure.Monitor" `
    --type "AzureMonitorWindowsAgent"

// modules/monitoring/data-collection-rule.bicep
param location string
param workspaceId string
param ruleName string = 'dcr-windows-security'

resource dcr 'Microsoft.Insights/dataCollectionRules@2022-06-01' = {
  name: ruleName
  location: location
  properties: {
    dataSources: {
      windowsEventLogs: [
        {
          name: 'securityEvents'
          streams: ['Microsoft-SecurityEvent']
          xPathQueries: [
            'Security!*[System[(EventID=4624 or EventID=4625 or EventID=4648 or EventID=4672 or EventID=4688 or EventID=4720 or EventID=4726 or EventID=4740 or EventID=4767)]]'
            'System!*[System[(EventID=7045 or EventID=7040)]]'
          ]
        }
      ]
      syslog: [
        {
          name: 'syslogAuth'
          streams: ['Microsoft-Syslog']
          facilityNames: ['auth', 'authpriv']
          logLevels: ['Info', 'Notice', 'Warning', 'Error', 'Critical', 'Alert', 'Emergency']
        }
      ]
    }
    destinations: {
      logAnalytics: [
        {
          name: 'sentinelWorkspace'
          workspaceResourceId: workspaceId
        }
      ]
    }
    dataFlows: [
      {
        streams: ['Microsoft-SecurityEvent', 'Microsoft-Syslog']
        destinations: ['sentinelWorkspace']
      }
    ]
  }
}

Data Collection Rules (DCRs) -- replacing server classes¶

DCRs are the Sentinel equivalent of Splunk deployment server classes. They define:

• What to collect -- specific event IDs, log facilities, performance counters
• How to transform -- KQL-based transformations at ingestion time
• Where to send -- Log Analytics workspace destination

3. Data source migration matrix¶

Network and firewall devices¶

Endpoint and identity¶

Cloud platforms¶

Security tools¶

Application and web¶

4. Content Hub solutions¶

Content Hub solutions are the Sentinel equivalent of Splunkbase apps. Each solution typically includes:

• Data connector -- instructions and configuration for data ingestion
• Analytics rules -- pre-built detection rules for the data source
• Workbooks -- dashboards for the data source
• Hunting queries -- threat hunting queries
• Playbooks -- automation playbooks

Deploying Content Hub solutions¶

# List available solutions
az sentinel solution list --resource-group "rg-sentinel" --workspace-name "law-sentinel"

# Install a solution (example: Palo Alto Networks)
az sentinel solution create \
    --resource-group "rg-sentinel" \
    --workspace-name "law-sentinel" \
    --solution-name "PaloAltoNetworks" \
    --plan publisher="paloaltonetworks" product="PaloAlto-Networks" name="PaloAltoNetworks"

5. Syslog and CEF collector deployment¶

Many network devices that sent syslog to Splunk Heavy Forwarders will send to a Linux log forwarder VM with AMA:

Architecture¶

Network Devices ──(syslog/CEF)──> Linux Forwarder VM ──(AMA)──> Log Analytics Workspace
                                       │
                                  AMA installed
                                  DCR configured
                                  rsyslog/syslog-ng

Deployment¶

# On the Linux forwarder VM:

# 1. Install Azure Monitor Agent
# (via Azure Arc or direct install)
wget https://aka.ms/azcmagent -O install_linux_azcmagent.sh
bash install_linux_azcmagent.sh

# 2. Configure rsyslog to receive remote syslog
cat >> /etc/rsyslog.d/50-sentinel.conf << 'EOF'
# Accept syslog from network devices
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

# CEF messages go to local4
local4.* /var/log/cef.log
EOF

# 3. Restart rsyslog
systemctl restart rsyslog

# 4. AMA DCR handles forwarding to Log Analytics
# (configured via Azure portal or Bicep)

6. Custom data ingestion (replacing HEC)¶

Splunk HTTP Event Collector (HEC) is replaced by the Log Analytics Data Collection API:

Splunk HEC equivalent¶

Splunk HEC:

curl -k https://splunk-hec:8088/services/collector \
  -H "Authorization: Splunk <hec-token>" \
  -d '{"event": "security event", "sourcetype": "custom:security", "index": "main"}'

Log Analytics Data Collection API:

# Using Data Collection Rule-based API
curl -X POST "https://<dce-endpoint>.ingest.monitor.azure.com/dataCollectionRules/<dcr-id>/streams/Custom-SecurityEvents_CL?api-version=2023-01-01" \
  -H "Authorization: Bearer <oauth-token>" \
  -H "Content-Type: application/json" \
  -d '[{"TimeGenerated": "2026-04-30T10:00:00Z", "EventMessage": "security event", "Severity": "High"}]'

7. Migration execution plan¶

Step 1: Inventory current Splunk data sources¶

| rest /services/data/inputs/all
| table title, disabled, sourcetype, index
| where disabled=0
| stats count by sourcetype, index

Step 2: Map to Sentinel connectors¶

For each active Splunk data source:

1. Check Content Hub for a matching solution
2. If no Content Hub solution, determine collection method (AMA, CEF, API, custom)
3. Document the target Sentinel table
4. Note any transformation requirements (field mapping, parsing)

Step 3: Deploy connectors in phases¶

Step 4: Validate data flow¶

// Verify data is flowing from each connector
union withsource=TableName *
| where TimeGenerated > ago(24h)
| summarize
    EventCount = count(),
    FirstEvent = min(TimeGenerated),
    LastEvent = max(TimeGenerated)
    by TableName
| sort by EventCount desc

8. CSA-in-a-Box data connector integration¶

Security data flowing into Log Analytics is automatically available to CSA-in-a-Box analytics:

Next steps:

• Dashboard Migration -- migrate Splunk dashboards to workbooks
• Historical Data Migration -- migrate Splunk index data
• Detection Rules Migration -- migrate correlation searches

Maintainers: csa-inabox core team Last updated: 2026-04-30