Zero data egress: verifying a migration without ever seeing the data

Every serious migration faces the same standoff. You want an independent check that the data survived the move intact — not the vendor's own word, not the migration tool grading its own homework. But the data in question is the most sensitive thing you own: policyholder PII, claims histories, account balances, decades of regulated records. The instinctive way to get independent verification is to hand a sample to a third party. For a CISO, that instinct is exactly the problem. The moment a copy of the book leaves your perimeter, you have created a new asset to defend, a new breach surface, and a new line item on every audit and subpoena for years.

The resolution is to stop treating "independent" and "in-house" as opposites. Verification can be independent of the migration and never leave your network. The trick is to move the engine to the data instead of the data to the engine.

The engine runs where the data lives

IronParse deploys inside the customer's perimeter — your VPC, your subnet, your air-gapped enclave if that's what governs the workload. It reads records locally, from the same storage the migration touches, under your own network controls and your own IAM. There is no outbound call carrying record contents, no upload step, no "send us a representative sample." The bytes never traverse a boundary they aren't already inside.

What does leave is a single artifact: a signed parity receipt. The receipt is the verdict, not the evidence it was computed from. It carries cryptographic hashes, field and record counts, and the pass or fail result of each verification gate. It does not carry a single record.

Why the receipt reveals nothing sensitive

This is the load-bearing claim, so it's worth being precise about it. The receipt is built from three kinds of values, and none of them can be reversed into your data.

Hashes are one-way. The receipt proves field-level fidelity with SHA-256 digests, not with the underlying bytes. A digest like 9f86d0… attests that a specific field decoded to a specific value without revealing what that value was; you cannot run SHA-256 backwards to recover a premium, a name, or an account number. Counts carry no content. "This record held eight coverage entries" or "the file contained 1,402,118 records" is a structural fact with no PII in it. Verdicts are booleans. "Gate 3 passed" tells an auditor the structure parsed and the round-trip matched; it says nothing about whose record it was.

receipt {
  records:        1402118
  fields_checked: 80
  gate.parse:          pass
  gate.roundtrip:      pass   sha256(re-encoded)==sha256(source)
  gate.field_count:     pass
  gate.type_decode:     pass
  gate.schema_compile:  pass
  signature:      ed25519 …
}

Hand that receipt to your security team, your auditor, or a regulator and they learn exactly one thing: whether the migration preserved the data. They learn nothing about the data. That separation — proof without contents — is what makes zero egress workable rather than a slogan.

The chain-of-custody dividend

Once the data never moves, a whole class of risk simply ceases to exist. There is no copy of the book sitting in someone else's cloud account, governed by someone else's access policy and someone else's incident-response maturity. There is no third-party API logging requests that might capture a field in transit. There is nothing for an attacker to breach at the vendor, and nothing for opposing counsel to subpoena from a processor you don't control. Your chain of custody stays a single link long: the data was read inside your perimeter and the verdict came out. Every vendor-risk questionnaire, every data-processing addendum, every "where does our PII go" question gets the same clean answer — nowhere.

A fidelity gateway at the boundary

This model matters more, not less, as the work continues past a single cutover. Legacy data does not migrate once and rest. It flows continuously — into cloud warehouses, into analytics pipelines, into the training and retrieval sets behind AI systems. Each of those flows crosses the same boundary, and each is another chance for a packed-decimal field or a variable-length array to be silently mangled on the way out.

The only verification model that scales with that traffic without widening the attack surface is one that sits at the boundary and inspects in place. Think of it as a continuous fidelity gateway: every batch that leaves the legacy estate is parsed and round-tripped where it sits, and only its receipt travels onward to prove it arrived intact. You get a standing, signed record of fidelity for every flow, and you add zero new places where the raw data can leak. Verification becomes a property of the boundary itself instead of a separate system you have to secure.

Independence and zero egress are not in tension

The fear that drives data out the door — "we can't trust the migration to grade itself" — is legitimate. But the cure was never to ship the data somewhere it can be checked. Independence comes from a deterministic engine that doesn't share the migration's assumptions and signs its own verdict. Zero egress comes from running that engine where the data already is. You can have both at once. The receipt is the thing that travels and the thing that proves the work; the data stays exactly where you are obligated to keep it.

Related: the spec · migration audit evidence

← All insights