A successful upgrade to today's connections can leave yesterday's records untouched. For a financial institution holding sensitive archives, the practical question is whether the data, its key-recovery path and its retained copies have all been included in the plan.
That is where a database can make a migration more manageable. 8DB, our omnimodal database, connects a declared protection transition with registered retained copies and checks on who may read a historical restore. The opportunity is a migration whose completion can be inspected, rather than inferred from the latest system configuration.
Use the roadmap to prioritize, not to guess
The G7 Cyber Expert Group's January 2026 roadmap supports coordinated planning across financial institutions and their providers. It is explicitly non-prescriptive and does not set regulatory expectations. Activities can overlap and be revisited; institutions are encouraged to prioritize according to risk and criticality.
The document discusses 2035 as an overall planning target and 2030–32 as an example for more critical systems. Those are not universal legal deadlines or a prediction of when a cryptographically relevant quantum computer will arrive. NIST's IR 8547, also relevant to transition planning, remains an initial public draft at this article's September 2026 review.
For an archive owner, that makes the first job concrete: identify the records that remain sensitive, the cryptography they depend on, and how long a safe transition would take. A dataset's age alone does not rank its exposure.
Follow the key as well as the ciphertext
An archive encrypted with AES-256 and a key envelope protected by a vulnerable public-key mechanism has a different dependency from an archive whose key never used that mechanism. NIST's PQC FAQ distinguishes symmetric cryptography from the public-key algorithms driving the transition. A complete review follows the route by which someone could recover the data key.
Ask where the root or key envelope lives, which backups retain it, and what an adversary could have copied. Separately, identify signatures used to authenticate historical records. Confidentiality and integrity need their own transition plans.
Prioritize archives by sensitivity, exposure, dependencies and migration difficulty. Our key-protection guide develops that distinction.
Archive migration · Evaluation map
A live-data upgrade leaves two more questions.
Follow the retained copy, then test who can read it after recovery.
- 01 · Live records
Which protection changed?
Identify the exact old and new profiles, including the path that protects the data key.
- 02 · Retained copies
What remains outstanding?
Account for the registered backups and exports included in the migration's completion decision.
- 03 · Historical restore
Who can read it now?
Test current-owner access and revoked-reader refusal against the required protection profile.
Dataset + declared transition + retained-copy scope + recovery evidence.
Make the archive's finish line visible
Imagine a customer-record archive whose live records have moved to a required protection profile. A registered export still uses the previous profile. The operator needs to see that retained artifact before declaring the scoped migration complete.
Then restore an older backup after one reader's access has been revoked. The recovery check should test whether the current owner can read the data and the revoked reader is refused. An intact backup and a correctly authorized restore answer different questions.
8DB's recorded native lifecycle qualification exercises this combination for HKDF-SHA256 to HKDF-SHA384 key derivation, with AES-256-GCM-SIV unchanged. A registered old archive blocks completion, and historical recovery is checked against the current required profile and authority. The migration evidence guide describes that bounded result.
Start an archive evaluation with that demonstrated lifecycle, then add the algorithm transitions, retained-copy coverage and service targets your institution needs. The result should be a migration your team can account for and a restore it can trust.
Give each team an answer it can use
The archive owner needs to know which declared copy remains outstanding. The security architect needs the exact old and new protection profiles. The recovery team needs an executable access check. The reviewer needs the records and artifacts behind the completion decision.
Keeping those questions connected is the value we want 8DB to bring to the program. A report that says “complete” is less useful than one that can show its dataset, transition, retained-copy scope and verification result.
Existing infrastructure belongs in the comparison. Oracle's documented online tablespace rekeying and Vault's Transit rotation and rewrapping provide useful mechanisms. Compare how the complete archive-and-restore workflow is assembled around them, using the same acceptance conditions as the 8DB evaluation.
Start with the copy that is hardest to account for
Choose one long-retention dataset and one backup or export that complicates its protection plan. Name the transition, the retained artifacts in scope and the access outcomes required after recovery. Include interruption and availability tests where they matter, and keep their results separate from historical-integrity checks.
The result should help your team decide what can proceed, what still needs work and what evidence supports that judgment. It should also leave a repeatable exercise for the next protection change.
Bring us one archive and one migration question. Include its sensitivity horizon, current protection, retained-copy paths and the outcome your reviewer needs to verify. We can define a focused evaluation around those conditions.
Evidence scope Primary roadmap reviewed · Recorded KDF and restore qualification · Evaluation guide. Explore the evidence. Methods and retained scope notes.