Migrating from Symantec DLP to Microsoft Purview DLP: a detailed, step-by-step plan

Moving from Symantec Data Loss Prevention to Microsoft Purview DLP isn't an export-and-import job. Symantec inspects data on detection servers and agents that you run and route traffic through; Purview evaluates content inside Microsoft 365 services and on onboarded devices, and reaches other channels through integrations. In this guide I'll walk through every phase, from inventory to decommissioning, with a mapping table for everything Microsoft's migration assistant can't move.

How the two platforms differ#

Symantec DLP is built around the Enforce Server, where you author policies, review incidents and manage roles, plus the detection points that do the inspection:

• Network Prevent for Email sits in the outbound SMTP path, behind Exchange Server or reached from Exchange Online through a connector, and blocks or modifies messages.
• Network Prevent for Web receives web requests from a proxy over ICAP, and Network Monitor inspects a copy of network traffic from a SPAN port or tap.
• Network Discover and Network Protect scan data at rest, such as file shares and SharePoint, and can quarantine or copy files.
• DLP Agents run Endpoint Prevent, which controls removable storage, printing, the clipboard, network shares, cloud storage and application file access, and Endpoint Discover, which scans local drives.
• Cloud Detection Service provides detection for Symantec's cloud services, such as its CASB and cloud web gateway.

Purview DLP has no servers in the data path. Policies are built in the Microsoft Purview portal (purview.microsoft.com), stored centrally and synced to Exchange Online, SharePoint, OneDrive, Teams, the Office apps and onboarded Windows 10, Windows 11 and macOS devices (the three most recent macOS versions). The Microsoft Purview Information Protection scanner covers on-premises file shares and SharePoint Server, Microsoft Defender for Cloud Apps covers non-Microsoft cloud apps, and a separate inline web traffic policy type covers unmanaged web and AI apps through Microsoft Edge for Business and network data security (SASE integrations). Every DLP-monitored activity lands in the audit log and activity explorer, and alerts go to the DLP Alerts dashboard and Microsoft Defender XDR.

So you migrate intent (which data, which channel, which action), not infrastructure. Policies move largely with tooling; classification built from your own data (EDM, IDM, VML) must be rebuilt; and channels Symantec covered by sitting in the traffic need a different Purview control or a documented decision to drop them.

Before you start#

• Roles. The migration assistant needs Global Administrator or Compliance Administrator. Use Compliance Administrator, because Microsoft recommends the least-privileged role. Exporting policies from Symantec needs the Author Policies privilege.
• Licensing. Microsoft says you need the appropriate DLP licensing for every location the migrated policies are scoped to. Check the Microsoft 365 service descriptions before you add Teams, devices or the inline web traffic locations.
• An admin workstation. The assistant is a Windows desktop application. It uses the Exchange Online PowerShell module, and Microsoft notes that Basic authentication must be enabled in WinRM on that computer.
• Owners. A data owner who can sign off each policy's matches, a messaging admin for mail routing and an endpoint admin for agents.
• Mailboxes on Exchange Server. Purview's Exchange location is Exchange Online. If mailboxes still live on Exchange Server, read Purview DLP and sensitivity labels with Exchange Server first, because those senders aren't covered the same way.

Phase 1: inventory Symantec DLP#

1. Export every policy, with its response rules. In the Enforce Server administration console, go to Manage › Policies › Policy List. Click a policy's export icon to get one XML file (named ENFORCEHOSTNAME-POLICYNAME-DATE-TIME.XML), or select several policies and click Export to get a ZIP archive. According to Broadcom, this export holds the rules and exceptions (including EDM, IDM, VML and Form Recognition definitions), endpoint locations and devices, sender and recipient patterns, response rules and data identifiers, but not the indexes, source data, training files, credentials or FlexResponse plug-ins. Don't use Export this policy as a template for this job: templates leave out response rules and custom or modified data identifiers.
2. List the detection methods in every rule: Described Content Matching (keywords, regular expressions and data identifiers), EDM and IDM profiles, VML profiles, Form Recognition, directory group conditions, file properties and sender or recipient patterns. Write down where each EDM source table, IDM document set and VML training set lives and who owns it; you'll need those files again.
3. List the channels that enforce each policy and how traffic reaches them: mail routing to Network Prevent for Email, the proxy's ICAP configuration, SPAN ports, Discover scan targets, agent channels and cloud integrations.
4. Record responses and the incident workflow: automated responses (block, modify, notify, user cancel, quarantine), the smart responses run by hand, incident statuses and attributes, who triages what, and where incidents go next (syslog, SIEM, ticketing).
5. Record roles: each Enforce role, its privileges and incident access conditions, and its members.
6. Take a baseline. Export incident counts per policy and channel for a representative period. They become your yardstick in Phase 5.

What good looks like: one row per policy, rule and channel, with its detection method, action, owner and baseline volume; every policy exported as XML; and every EDM, IDM and VML source located.

Map Symantec concepts to Purview#

Use this table to decide, row by row, what the assistant moves, what you rebuild and what you replace with a different control. The assistant notes come from Microsoft's mapping documentation.

Phase 2: prepare Purview#

1. Design the target policy set. Decide which Symantec policies become one Purview policy with several rules, agree a naming convention and set priorities. A Symantec rule that blocked email but only notified on endpoints becomes two rules, because Purview actions depend on the location (see designing Purview DLP policies).
2. Settle classification first. List the built-in SITs that match your data identifiers, so the assistant maps to them instead of creating duplicates. Microsoft warns of a limit of 10 rule packages per tenant, and piles of duplicate custom SITs bring you closer to it. See custom sensitive information types.
3. Onboard devices. Windows devices already onboarded to Defender for Endpoint don't need a second package; others onboard under Settings › Device onboarding › Onboarding. Configure the endpoint DLP settings (restricted apps, unallowed browsers, service domains, removable storage and printer groups) before you migrate endpoint rules: endpoint DLP onboarding and endpoint DLP settings.
4. Prepare alert handling. Decide who triages in the DLP Alerts dashboard and who works DLP incidents in the Defender portal under Incidents & alerts › Incidents; see investigating Purview DLP alerts.
5. Tell users. Purview policy tips look different from Symantec's notifications, and they appear during simulation if you turn them on.

What good looks like: pilot devices listed with healthy policy sync, built-in SITs chosen for your main data identifiers, and alert owners able to open the dashboards.

Phase 3: migrate policies with the migration assistant#

1. Install the assistant on the admin workstation. The first time only, start it with Run as administrator, so it can install missing components. Select Get Started and sign in.
2. Choose Symantec DLP as the source and upload one to three XML files per run; Microsoft recommends that to keep the later steps manageable. Unzip bulk exports first, and upload only Symantec policy exports.
3. Review the mapping. A row with no status migrates cleanly; Informational rows are resolved automatically; Needs Review rows need your input; Unsupported rows must be rebuilt by hand afterwards. Point data identifiers at existing SITs in the Target column wherever you can, as Microsoft strongly recommends. Extend a policy to more locations only on purpose: conditions a location doesn't support, such as the email subject, are dropped, so the new policy can be broader than intended.
4. Read the premigration feasibility report, then merge rules into target policies and set each policy's state. Pick simulation with policy tips, not On.
5. Select Start Migration. A PowerShell window asks you to sign in again, then creates the SITs and policies. Keep the tool open; if creation fails you can choose Try Again, Rollback failed policies or Rollback all changes for the session. A rollback can take two to four hours, and the window must stay open throughout.
6. Save the technical report, an Excel workbook with Overview, Policy Details and SIT Details sheets, and attach it to your inventory.
7. In the Purview portal, open Information Protection › Classifiers, select Sensitive info types and sort by publisher: the new SITs are published by DLP Migration Tool. Rename the ones named after rules with roman numerals (you can't rename them inside the assistant), then check case sensitivity, word versus string matching, proximity and validators.
8. Open each migrated policy and add what's missing. Microsoft notes that the current version brings policies over with Generate Incident Report as the default action and that some elements can be dropped, so set actions, notifications and overrides yourself from your Phase 1 record.

Connect-IPPSSession
Get-DlpCompliancePolicy | Format-Table Name,Mode,Priority -AutoSize
Get-DlpCompliancePolicy -Identity "MIG - Card data - Email" -DistributionDetail |
  Format-List Name,Mode,DistributionStatus,DistributionResults

What good looks like: every migrated policy is in simulation mode with a DistributionStatus of Success, and every rule the report marked partial or unsupported has an owner and a planned fix.

Phase 4: rebuild what the assistant can't move#

EDM profiles become EDM-based SITs#

Export the same source table, define the schema (the new experience can build it from a small sample file with non-sensitive values in the real format), create the EDM SIT, and have a member of the EDM_DataUploaders group hash and upload the data with the EDM Upload Agent. Microsoft documents tables of up to 100 million rows, refreshable daily. Walkthrough: exact data match in Purview.

IDM profiles become document fingerprints#

Fingerprint the blank forms and templates the IDM profile represents, not every finished document. Fingerprint SITs work in DLP policies for Exchange, SharePoint, OneDrive, Teams and devices, and support partial and exact matching. Microsoft notes that files to be scanned can't be password protected and that text in embedded documents isn't used when the fingerprint is created; its document fingerprinting page also carries a licensing note worth reading.

VML profiles become trainable classifiers#

Check the built-in trainable classifiers first. If none fits, create a custom classifier with examples from the VML positive training set as seed content, and test it before you use it in DLP: trainable classifiers and content explorer.

Directory group conditions#

Express them as the policy's scope (include or exclude users and groups) or, for email, the "Sender is a member of" condition. In PowerShell, -ExchangeSenderMemberOf on Set-DlpCompliancePolicy scopes the Exchange location to the members of a group, which also gives you an easy pilot scope.

Response rules and smart responses#

Rebuild each automated response as actions in the rule: restrict access or block, block with override, policy tips, user notifications, incident reports and alerts (for email, see email blocked by Purview DLP). Smart responses have no direct counterpart; agree with the SOC how alerts are assigned and classified in Defender XDR, and automate the rest in your SIEM or SOAR.

Phase 5: prove detection parity in simulation#

1. Build a test corpus per rule: samples that must match, near-misses that must not, and edge cases (archives, PDFs, scanned images, other languages). Use synthetic data in the real formats, never live customer records.
2. Test classification directly in Security & Compliance PowerShell. Test-DataClassification returns each SIT found with its count and confidence; Test-TextExtraction reads unencrypted email message files, so save test emails as .msg.
   PowerShell

   $r = Test-DataClassification -TextToClassify (Get-Content .\parity-sample-01.txt -Raw)
   $r.ClassificationResults
   $content = Test-TextExtraction -FileData ([System.IO.File]::ReadAllBytes('.\parity-sample-02.msg'))
   Test-DataClassification -TestTextExtractionResults $content.ExtractedResults

3. Run the corpus through both systems while Symantec still enforces and Purview is in simulation: send the test emails, share the files from a pilot site, and copy them to USB storage or print them on pilot devices.
4. Compare per rule: Symantec incidents against the Purview simulation results and the DLPRuleMatch events in activity explorer. Then compare at least a week of real volumes with the Phase 1 baseline.
5. Tune and repeat: for misses, check the SIT, confidence level and instance count; for extra matches, raise them or add supporting elements and exceptions (tuning false positives).

What good looks like: every must-match sample hits the intended rule, near-misses don't, real volumes are close to the baseline or the difference is explained, and the data owner has signed off the rule. The general simulation workflow is in from simulation mode to enforcement.

Phase 6: parallel run and cutover by location#

Cut over in this order: Exchange, then SharePoint, OneDrive and Teams, then endpoints, then on-premises repositories and web channels. For each location, turn the Purview rules on (notify and override first, block later) and stop Symantec enforcement on that channel in the same change window, so users never get two verdicts for one action. Microsoft says policies generally take effect about an hour after you turn them on, so plan the window around that.

Exchange: take Network Prevent for Email out of the mail path#

In Exchange Online, look for a mail flow rule that routes outbound mail to a connector, the outbound connector that points at the detection servers and, if they reflect scanned mail back, the inbound connector that accepts it. Find them, then disable the rule and the outbound connector:

# Exchange Online PowerShell
Get-TransportRule | Where-Object { $_.RouteMessageOutboundConnector } |
  Format-Table Name,State,Priority,RouteMessageOutboundConnector -AutoSize
Get-OutboundConnector | Format-Table Name,Enabled,IsTransportRuleScoped,SmartHosts -AutoSize
Disable-TransportRule -Identity "Route outbound mail to Symantec DLP"
Set-OutboundConnector -Identity "Symantec DLP Network Prevent" -Enabled $false

With Exchange Server, the detection servers are smart hosts on a send connector; disable it and enable the connector that sends mail onward directly. Connector design, Trial Mode and loop symptoms are covered in Symantec DLP Network Prevent for Email with Exchange Server.

# Exchange Management Shell (connector names are examples)
Set-SendConnector "Outbound via Symantec DLP" -Enabled $false
Set-SendConnector "Internet direct" -Enabled $true

Remove inbound connectors and relay permissions for the detection servers only after the rollback window ends. Good looks like message trace showing test mail leaving without the Symantec hop, the Purview policy tip while composing, and the expected block or override on send.

SharePoint, OneDrive and Teams#

Turn the Purview rules on, then disable the Symantec Discover targets or cloud integrations for the same sites so files aren't remediated twice. Location-specific behavior is in SharePoint and OneDrive and Teams.

Endpoints, ring by ring#

Turn the Purview device rules on for a ring, confirm what users see, then remove the DLP Agent from that ring. The agent is deliberately hard to remove: if an uninstall password is set, pass it on the command line. The product code is in the Uninstall registry entry whose DisplayName contains "AgentInstall":

Get-ChildItem HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall |
  Get-ItemProperty | Where-Object { $_.DisplayName -like '*AgentInstall*' } |
  Select-Object DisplayName, DisplayVersion, UninstallString

Then run Broadcom's documented command from an elevated command prompt or your software distribution tool:

msiexec /uninstall <product code> /q UNINSTALLPASSWORD="<password>"

By default, three wrong passwords end the uninstall (the UninstallPassword.RETRY_LIMIT agent setting). If nobody knows the password, DLP 15 and later let you push a new one from System › Agents › Agent Password, which reaches only agents that are connected. Broadcom provides a separate uninstall tool for Mac agents.

Repositories and web#

For file shares and SharePoint Server, deploy the scanner, add the On-premises repositories location (scanner install and errors) and disable the matching Discover targets. For uploads from managed devices, use endpoint DLP's browser and cloud egress controls and the Purview extension for Chrome and Firefox; for unmanaged apps, evaluate the inline web traffic policies. Then remove the ICAP service from your proxies and the SPAN or tap feeds for Network Monitor.

Rollback plan#

Keep the Symantec platform running, patched and supported until the last location has been stable for an agreed period. Agree rollback triggers in advance (a business process blocked by false positives, a must-match sample that stops matching, mail delays). Each rollback reverses one switch:

• A Purview policy misbehaves: put it back into simulation, or turn it off. Allow for policy sync time; this isn't instant either.
• Email: re-enable the transport rule and outbound connector in Exchange Online, or swap the send connectors back on Exchange Server.
• Endpoints: set the ring's Purview rules to audit, and redeploy the DLP Agent from the packages you kept.
• A bad assistant run: use the assistant's rollback while the session is open; afterwards, delete the policies and the SITs published by DLP Migration Tool in the portal.

Set-DlpCompliancePolicy -Identity "MIG - Card data - Email" -Mode TestWithoutNotifications
# Exchange Online PowerShell
Enable-TransportRule -Identity "Route outbound mail to Symantec DLP"
Set-OutboundConnector -Identity "Symantec DLP Network Prevent" -Enabled $true

What good looks like: written rollback steps per location, tested once during the pilot, that the on-call admin can run without the project team.

Decommission checklist#

• Keep or export the Symantec incident data your retention obligations require; the assistant migrates policies, not incidents, so Purview alerts start empty.
• Remove the mail routing: transport rules, outbound and inbound connectors in Exchange Online, send connectors on Exchange Server, and relay permissions for detection servers on the next hop.
• Remove the ICAP configuration from web proxies and the SPAN or tap ports used by Network Monitor.
• Uninstall DLP Agents everywhere, including servers and virtual desktops, and remove the agent packages from your software distribution.
• Disable Discover scan targets and Symantec cloud integrations; delete their service accounts, stored credentials and directory connections.
• Repoint the SIEM from Enforce syslog to Defender XDR incidents; update runbooks, help desk scripts and user guidance.
• Consolidate the migrated SITs and delete the ones no policy uses.

Tips and gotchas#

• Stored email is out of scope. Purview DLP evaluates new email, not items already in mailboxes; use a content search for a one-off check.
• Endpoint DLP needs Defender Antivirus running, in active or passive mode. On a client with another antivirus and no Defender for Endpoint onboarding, Defender is disabled (active, passive and EDR block mode). Replacing Symantec Endpoint Protection too? Plan it together with the move to Defender for Endpoint.
• Check platform coverage. Microsoft lists Windows 10, Windows 11 and the three most recent macOS versions for endpoint DLP. If Symantec agents also protect servers or other platforms, decide how those are covered before you remove them.
• Two DLP agents on one device is a pilot-only state. Measure performance and application compatibility on the pilot ring before you widen it.
• Related: policy distribution errors and the DLP messages quick reference.

References#

• Learn about the Microsoft Purview Data Loss Prevention migration assistant for Symantec and Forcepoint (Microsoft Learn)
• Use the Microsoft Purview Data Loss Prevention migration assistant for Symantec and Forcepoint (Microsoft Learn)
• About policy export (Broadcom Tech Docs)
• Using uninstallation passwords (Broadcom Tech Docs)