Migration guide
Teams move from Presidio to Philter when their prototype needs to be productionized, when they need domain-tuned NLP models rather than generic spaCy, or when they need a policy engine richer than Presidio's recognizer registry. This guide covers the concept mapping, the migration steps, and the operational differences.
The reasons teams give for migrating off Presidio, ordered by how often we hear them.
Presidio is a strong Python prototyping framework. Going to production (a stable API, HA deployment, monitoring, audit logs, marketplace billing) is work teams would rather not own. Philter ships as a turnkey API with the operational surface already built.
Presidio's default analyzers use generic spaCy or transformer models. Philter ships purpose-trained lenses for healthcare and other domains, with measurably higher precision and recall on those text types.
Presidio's AnalyzerEngine + AnonymizerEngine covers detection and replacement. Philter adds severity scoring, conditional rules, format-preserving encryption, synthetic-value replacement, and per-entity strategies that go beyond Presidio's anonymizers.
How Presidio concepts translate to Philter equivalents. The mapping is mostly direct; Philter's engine is a superset of Presidio's recognizer model.
| Microsoft Presidio | Philter | Notes |
|---|---|---|
AnalyzerEngine | Philter detection (regex + dictionaries + PhEye lenses) | Same role: find entities in text. Philter's pattern layer covers Presidio's regex recognizers; PhEye covers Presidio's NLP-based recognizers. |
AnonymizerEngine | Filter strategies (mask, redact, encrypt, FPE, replace, abbreviate) | Philter offers more strategies, including format-preserving encryption and deterministic synthetic-value replacement. |
| Built-in recognizers (PERSON, EMAIL, SSN, etc.) | Default policy entities | Direct one-to-one mapping for most common entity types. Philter ships additional ones (medical record numbers, custom identifiers) out of the box. |
Custom PatternRecognizer | Custom identifier definitions in policy JSON | Define your own regex, dictionaries, or identifier patterns in the policy file. No Python class to subclass. |
| Context-aware recognizers (with NLP) | PhEye lenses (purpose-trained models) | Philter's lenses are purpose-trained for PII/PHI detection, not generic NER. Healthcare and other domain lenses are available out of the box. |
| Operator config (mask, redact, replace, hash) | Per-entity filter strategy in policy | Configured per entity type in the policy JSON. Conditional rules and severity scoring give you finer control. |
presidio-analyzer Python package | Philter API (HTTP) or Phileas library | Philter is a turnkey HTTP service. If you want an embedded library, use Phileas (Java, Python, .NET, Go). |
| Docker images on quay.io | AWS / GCP / Azure marketplace or self-built container | Philter is available on the cloud marketplaces for one-click deploy, or as a container image for custom builds. |
A safe migration runs Philter in parallel with Presidio against a sample of production text, validates parity, then cuts over. Most teams complete the migration in one to three weeks.
List every recognizer your Presidio deployment uses: built-ins, custom PatternRecognizers, NLP-based ones. Note the operators (mask, redact, replace) applied to each. This becomes your initial Philter policy.
Pattern recognizers become regex or identifier entries in the policy JSON. NLP recognizers map to PhEye lens entries. Operators map to per-entity filter strategies. Use the Redaction Policy Editor to build this interactively.
Deploy Philter from a cloud marketplace or as a container in your existing infrastructure. Keep Presidio running. No application code changes yet.
For a sample of production traffic, send text to both Presidio and Philter. Compare entity detections side by side. Tune the Philter policy to close any meaningful gaps, especially for domain-specific entities where PhEye lenses should outperform generic NER.
Switch one application or pipeline at a time from Presidio to Philter. Monitor entity-type counts and processing latency. The Philter API and the Presidio HTTP wrapper expose similar input/output shapes, so the application-code change is usually a few lines.
Once all integrations are stable on Philter, remove the Presidio service and its dependencies. The maintenance burden goes with it.
Presidio is typically deployed as two Python services (analyzer and anonymizer) that your application calls. Philter is a single container that exposes a unified redaction API. For HA, run two or more Philter instances behind an internal load balancer. The PhEye model server runs as a sidecar or shared service that Philter calls for NLP-based detection.
Presidio is free open source; the cost is your operational time to deploy, monitor, scale, and maintain it. Philter on the cloud marketplaces is $0.49/hr per instance, which covers a turnkey API with vendor support, marketplace billing, and the PhEye lens models. For most teams, the cost trade-off comes out in favor of Philter once you include engineering time spent operating Presidio in production. The open-source Phileas library is also free if you want to embed the engine directly without running a service.
A 30-minute call with Jeff covers your current setup, the migration path that fits your stack, and where the gotchas usually live. No sales pitch.