The migration job reports success. The live database opens under its new configuration. Then someone restores an older archive.
Is the migration still complete?
The answer depends on what the team promised to change and which copies it included. Defining those boundaries early makes the work easier to operate, evaluate and repeat. It also gives a buyer something more useful than a green status light.
8DB's approach brings protection versions, declared retained copies and recovery authority into the lifecycle of the database. A recorded key-derivation migration provides a concrete example of how those responsibilities can be checked together.
Name the change before defining success
Teams use “re-encrypt” for several different operations. Separating them prevents a successful step from being mistaken for the whole transition.
| Operation | What changes | Useful completion evidence |
|---|---|---|
| Key rotation | Key material or epoch | New writes use the intended key; historical reads and retirement rules behave as specified |
| Key-protection transition | Establishment or wrapping of keys | Required dependencies change, with old envelopes accounted for |
| Payload-cipher change | Encryption of stored content | Declared ciphertext is converted, excepted or scheduled; interruption behavior is tested |
| Signature transition | Authentication of objects or manifests | New evidence binds the intended content; historical validation rules remain explicit |
| Authorization transition | Permission to recover or use data | Recovery enforces the required current authority, including revocations |
These are planning categories, not a claim that every migration requires all five or that one command implements them all. Choose the rows that match your threat model and actual design.
NIST's crypto-agility guidance treats replacement and adaptation of cryptography as a system capability that must preserve security and operations. The practical implication is to write down what changes, what stays available and how each obligation will be checked. NIST CSWP 39, updated June 2026
What changed, and what would prove it?
Key material or epoch
Verify new writes, historical reads and retirement behavior.
Completion for one operation or subset does not establish completion for the others.
Make completion a statement about a declared set
Imagine a test dataset with live records and a registered archive. The live records have been converted. The archive has not.
“Live conversion complete” may be accurate. “Dataset migration complete, including the archive” would require another action or a documented exception accepted under the evaluation contract. Good accounting preserves that distinction.
For your own transition, name the dataset, source versions, target protection, retained-copy manifest and exception rules. Then attach the outcomes. A missing artifact should remain visible as missing, rather than becoming an assumed success.
Our copy-inventory guide helps define the set. Its examples include derivatives and exports because the information you need to protect may extend beyond the primary table.
A concrete 8DB starting point
The retained 8DB qualification records a transition from HKDF-SHA256 to HKDF-SHA384 with the same AES-256-GCM-SIV payload mode. Its bounded native restore case checks current-owner access, revoked-reader refusal and the required current derivation version and epoch. A registered old archive remains a completion blocker until its obligation is resolved.
Protection changes, retained-copy accounting and current-authority checks work together in the demonstrated lifecycle. The next evaluation can extend that foundation to the algorithm transition and service target your application needs.
A customer evaluation should extend the declared case to the operations, failure modes and deployment it needs. Our repeatable migration guide describes that approach, and the backup article develops the revoked-reader exercise.
Ask for a result another person can check
A useful completion packet contains the input identities, target configuration, declared copies, exceptions and observed outcomes. Keep evidence of refusal as well as success: the wrong dataset, stale authority or an omitted copy should not receive the same result as a valid completed transition.
That packet supports a better next decision. An operations team can see what remains. A reviewer can inspect the scope. A future migration can start from a known state.
Tell us which transition you need to run. Name the data class, the protection change and the recovery behavior that matters. We can turn those into a bounded 8DB evaluation with a finish line everyone can inspect.
Evidence scope Primary guidance · Recorded bounded lifecycle qualification. Explore the evidence. Methods and retained scope notes.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work