Migration guide
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.
The reasons teams move a workload off Skyflow and onto Philter. Note that some Skyflow use cases should not move at all.
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.
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.
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. |
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.
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.
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).
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). The original values never enter a vault on this path.
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.
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.
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.
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.
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.