---
title: "Migrate from Skyflow to Philter"
description: "Moving from a Skyflow data privacy vault to Philter is a re-architecture, not an API swap. When the move makes sense, and how to translate it safely."
url: "https://philterd.ai/migrate/from-skyflow/"
---

[← All comparisons](https://philterd.ai/compare/)

Migration guide

# Migrate from Skyflow to Philter

This is the one migration guide on the site that starts with a warning: moving from Skyflow to Philter is not a like-for-like API swap, because they are different categories. Skyflow is a managed vault that stores sensitive values and returns tokens; Philter is a self-hosted engine that redacts and de-identifies text in your pipeline. You only migrate the parts of a Skyflow deployment that were really a redaction problem in disguise. This guide helps you separate those from the parts that genuinely need a vault, and translate the former.

[Deploy Philter in 5 minutes](https://philterd.ai/philter/deploy/)

## Why teams migrate

The reasons teams move a workload off Skyflow and onto Philter. Note that some Skyflow use cases should not move at all.

### The workload was redaction, not retention

A common pattern: a vault was adopted to keep PII out of logs, analytics, or LLM prompts, where the original value was never actually needed again. That is a redaction problem. Removing the data outright with Philter is simpler than tokenizing, storing, and governing data you only wanted gone.

### Data must stay self-hosted and open source

Skyflow is a managed vendor, even in a bring-your-own-cloud deployment. If your posture requires that sensitive values never reach a vendor's software and that the privacy logic be auditable, Philter runs entirely in your environment under Apache 2.0.

## Concept mapping

Skyflow concepts do not map one-to-one to Philter, because tokenization and redaction are different operations. This table translates intent, and flags where there is no equivalent because the need itself should be reconsidered.

| Skyflow | Philter | Notes |
| --- | --- | --- |
| Vault · stores the original value | No equivalent (by design) | Philter does not store sensitive values. If a field genuinely must be retained and retrieved, keep it in the vault; do not migrate that field to Philter. |
| Tokenize · return an opaque token | Redact, or format-preserving encryption | If the token was only ever a placeholder you never redeemed, redact instead. If you do need reversibility, format-preserving encryption keeps a usable, format-valid value without a separate store. |
| Detokenize · retrieve the original under policy | FPE decryption (key holder) or not reversible at all | Map each detokenization path explicitly: is it a real retrieval need (keep it in a vault), a reversible-by-the-key-holder need (FPE), or something that never needed reversing (redact)? |
| Vault schema and field tokenization config | Policy `identifiers` and filter strategies | Per-field tokenization rules become per-entity policy rules: which identifiers to act on and how (mask, redact, encrypt, FPE, replace). |
| Policy-based detokenization access control | Key management + network and API authentication | Skyflow governs who can detokenize. With Philter, reversibility is governed by who holds the FPE key and by network/API access to the service. Re-implement only the access controls that correspond to real retrieval needs. |
| Structured-record vault operations | Unstructured-text redaction | Philter is built for free text and PDF. Purely structured fields that need retention are a vault job, not a Philter job. |

## Migration steps

The migration is a classification exercise first, then a translation. Most of the effort is deciding which fields move and which stay. Plan four to eight weeks depending on how many integration points are involved.

1. ### Classify every tokenized field
   
   For each field Skyflow tokenizes, answer one question: do you ever detokenize it for a real business need? Fields you retrieve (billing, fulfillment, KYC) stay in a vault. Fields you tokenize but never meaningfully redeem (PII in logs, analytics, prompts) are redaction candidates.
   
2. ### Design Philter policies for the redaction candidates
   
   For each field that should move, write the policy: the entity types involved and the strategy (redact for never-retrieved data, format-preserving encryption for reversible-by-key-holder data).
   
3. ### Deploy Philter in the pipeline
   
   Deploy Philter from a marketplace or your own registry into your environment, positioned where the text flows (in front of your log shipper, your warehouse loader, or your LLM calls via the [proxy](https://philterd.ai/philter-ai-proxy/)). The original values never enter a vault on this path.
   
4. ### Run shadow mode on the redaction candidates
   
   For a sample of the relevant flows, run Philter and compare the de-identified output against what you expect. Tune the policy. Because this is a different operation than tokenization, validate on the redacted output itself, not against Skyflow tokens.
   
5. ### Cut over the redaction flows, keep the retention flows
   
   Switch the redaction-candidate flows to Philter. Leave the genuine retention-and-retrieval fields in Skyflow. It is normal and correct to end with a smaller vault plus Philter, rather than no vault at all.
   
6. ### Right-size or wind down the vault
   
   With redaction moved out, the remaining vault footprint should be smaller (fewer fields, lower volume), which usually means a smaller contract. Wind it down entirely only if no field genuinely needed retention.
   

## Architecture changes

Skyflow's path routes sensitive data into a managed vault and returns tokens, with detokenization later under policy. Philter's path keeps data in your perimeter and removes or transforms it inline: application sends text to a self-hosted Philter service and gets de-identified text back, with no store behind it. The migration replaces the vault round-trip with an inline redaction step for every flow where the original value was not actually needed again. For flows where it was needed, the vault round-trip stays. The end state is commonly a hybrid: a slimmer vault for true retention, Philter for everything that was only ever meant to be cleaned.

## Common pitfalls

- **Migrating fields that genuinely need retention.** The biggest mistake is trying to replace the vault wholesale. If a field is detokenized for a real business reason (billing a stored card, retrieving an ID for KYC), it belongs in a vault. Philter does not store values, by design. Classify first.
- **Treating redaction as reversible tokenization.** Plain redaction is one-way. If you assumed every value could be recovered the way detokenization recovers it, you will be surprised. Use format-preserving encryption for the values that truly need to be reversible, and be explicit about which those are.
- **Skipping the classification step.** Jumping straight to "swap the API" fails here because there is no equivalent API. The work is deciding, field by field, retain-and-retrieve versus remove-from-flow. Do that first; the translation is straightforward once the classification is done.

## Further reading

- [Philter vs Skyflow](https://philterd.ai/compare/philter-vs-skyflow/): The category distinction between a redaction engine and a data privacy vault, and when each fits.
- [What is format-preserving encryption?](https://philterd.ai/blog/what-is-format-preserving-encryption/): Philter's reversibility model for the fields that need to be recoverable without a vault.
- [Why API-based redaction is a security antipattern](https://philterd.ai/blog/why-api-based-redaction-is-a-security-antipattern/): Why keeping sensitive data inside your perimeter beats routing it through a managed service.

## Plan the migration with the team that built Philter

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.

[Deploy Philter in 5 minutes](https://philterd.ai/philter/deploy/)