04 / Enterprise migration · Publicly shipped

Thousands of policies.
A more practical way forward.

Co-owning the backend of a desktop tool that helps enterprises move data loss prevention policies from Symantec and Forcepoint to Microsoft Purview.

Context
Microsoft · Microsoft Purview DLP
My role
Backend co-owner; mapping engine implementation
Technologies
C# / .NET, WPF, PowerShell, XML, SQL backups

40+

Enterprise customers, each with 1,000+ policies.

Guided automation replaced weeks of manual policy-migration work. The assistant is publicly available, with official Microsoft documentation.

Migration is a translation problem.

An enterprise DLP policy estate is more than a collection of settings. It contains sensitive information types, regular expressions, keywords, and rules that have to be understood in the target platform’s terms.

Moving thousands of policies from Symantec or Forcepoint to Microsoft Purview manually meant weeks of work. A useful migration tool needed to translate policy intent, not simply copy configuration.

My contribution

I co-owned the backend of the publicly shipped DLP Migration Assistant and built its policy-mapping engine.

The engine maps policy constructs from Symantec XML exports and Forcepoint SQL backups into Microsoft Purview policies and scripts. That includes mapping sensitive information types, regular expressions, and keywords.

The product is a Windows desktop application. My contribution was the backend and mapping work, within a broader team-delivered tool.

From source constructs to target policies.

The mapping engine connects the source policy representation to the constructs supported by Microsoft Purview. The broader assistant wraps that work in a guided migration experience.

  1. Interpret the source

    Work with Symantec policy XML exports and Forcepoint backup data to identify the sensitive information types, regular expressions, and keywords to translate.

  2. Map policy meaning

    Map the source constructs into Microsoft Purview equivalents and scripts rather than treating migration as a file-format conversion.

  3. Support a guided migration

    The publicly documented assistant analyzes inputs, maps supported constructs, executes PowerShell-based migration, and reports migration status and recommendations.

Tool capability: official documentation describes supported constructs and migration limitations, including partial and unsupported mappings. Guided automation does not mean every source policy has a direct equivalent.

A shipped tool for a real adoption barrier.

The assistant supported 40+ enterprise customers, each with 1,000+ policies, replacing weeks of manual work with guided automation. This describes the scale of the supported migrations and the manual effort addressed, not a measured end-to-end completion time.

The work is publicly visible through the OfficeDev repository and Microsoft Learn documentation. The documentation covers the product’s behavior and supported mappings; the individual contributions described above are my own project experience.

Good migration tooling makes the translation explicit, so adoption is not held back by manual repetition.

Want to talk about enterprise migration tooling?

kumarnikhil374@gmail.com