The National Institute of Standards and Technology (NIST) estimates that a large agency needs three to five years to complete a post-quantum migration, once fully resourced. Larger or more heterogeneous estates (multiple data centers, decades of acquisitions, mainframes and cloud platforms running side by side) should plan for the upper end of that range or beyond. Count backward from the federal deadlines, add the months it takes to secure funding and staff a program, and the window to start planning is already narrow.
That timeline assumes something most organizations don’t yet have: a plan that tells them what to change first. An inventory shows where quantum-vulnerable cryptography lives. A roadmap decides what happens to it, in what order, and with what resources. If 500 systems contain vulnerable cryptography, dividing 500 by the years remaining doesn’t produce a plan, and a date without dependencies, ownership, and capacity behind it is only an aspiration.
This is the seventh post in our eight-part quantum readiness series. The previous post examined why legacy code is the hardest part of the quantum transition. This one is practical: how to move from a cryptographic inventory to a migration roadmap that holds up under schedule pressure.
“Fully Resourced” Is Doing a Lot of Work
The phrase “once fully resourced” deserves a closer look. Most programs don’t start that way. They start with a small team, a partial inventory, and a budget request competing with every other priority on the CIO’s list, and the time spent getting fully resourced comes out of the same window.
The final deadline is also not the date to plan against. NIST’s draft transition guidance (IR 8547) deprecates today’s quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035, and National Security Systems encounter earlier CNSA 2.0 milestones. For the most important systems, 2030 is the practical planning horizon.
Prioritize by Confidentiality Horizon, Not Convenience
The natural instinct is to start with what is easiest. Upgrade the TLS libraries, swap a few certificates, and report early progress. That approach produces good status reports but poor risk reduction.
A better starting question is how long the data needs to stay secret. Data whose confidentiality horizon (the period during which disclosure would still cause harm) extends past the arrival of a cryptographically relevant quantum computer is already exposed to harvest-now, decrypt-later collection. Health records, intellectual property, and personnel files can carry horizons of 25 years or more.
Michele Mosca, co-founder and deputy director of the Institute for Quantum Computing at the University of Waterloo, framed the problem years ago. If the time your data must remain secure, plus the time it takes to migrate, exceeds the time until a quantum computer can break current encryption, you are already late. Long-horizon systems go first, especially when they are hard to change.
Score Every System the Same Way
A defensible roadmap applies one consistent set of criteria across the portfolio, so executives, auditors, and program offices can understand sequencing decisions. We recommend scoring each system on four dimensions:
- Confidentiality horizon, or how long the protected data must remain secret.
- Exposure, meaning whether the system moves data across boundaries where it can be captured, or anchors the identity, authentication, and digital signatures other systems trust.
- Business criticality, including what fails (and who notices) if the system is disrupted during migration.
- Migration complexity, which covers hardcoded algorithms, vendor dependencies, platform age, interface constraints, and test coverage.
The fourth dimension is where most roadmaps go wrong. A system with long-horizon data and high migration complexity doesn’t belong at the end of the plan because it is difficult. It belongs near the front because it takes the longest to reach readiness. Low-horizon, low-complexity systems can follow the normal vendor upgrade cycle.
Build the Roadmap in Waves
A roadmap that assigns every application a date in one long list will break at the first slip. Organize the work in waves, each with clear entry criteria, scope, and exit criteria, so the program can absorb delays without losing its sequence.
The first wave usually covers foundations: crypto-agility in shared services, PKI readiness, procurement language that requires quantum-ready products, and a handful of pilots chosen to represent the estate (a modern application, an infrastructure service, a vendor-managed platform, and at least one difficult legacy application). Those pilots replace guesswork with real numbers and produce reusable patterns for hybrid deployment, testing, and rollback. The second wave takes on high-horizon, high-exposure systems, including legacy applications that need dependency analysis or refactoring first. Later waves absorb lower-risk systems, vendor-managed products, and the long tail of internal tools.
Combined methods (classical and post-quantum algorithms combined during the transition) let teams reduce risk without betting everything on a single cutover date. They are especially useful in interfaces where partners and suppliers move at different paces.
Plan Backward from the Hard Dates
The safest way to test a roadmap is to work backward. Start with the date a system must be quantum-ready, then subtract deployment, authorization, testing, remediation, vendor lead time, procurement, and discovery. The result is the latest credible start date. Two systems targeted for 2031 can look identical on a spreadsheet, yet one needs engineering to begin in 2027 because of a platform upgrade and interface changes, while the other can wait until 2029 for a vendor release. The deadline is the same. The critical path is not.
Capacity must pass the same test. If the roadmap assumes 80 migrations per year and the organization can realistically complete 25, the plan fails on arithmetic before the first project begins. Funding matters, but so do engineers, application owners, test environments, and change windows.
Name the Systems That Won’t Cooperate
Every portfolio has applications that can’t meet the present timeline. The vendor has no upgrade path. The platform can’t handle larger keys and signatures (an ML-DSA signature runs to several kilobytes, compared with 256 bytes for RSA-2048). The code has no automated tests, and no one remembers why the encryption routine works the way it does.
The roadmap should identify these systems early and assign each one of them a decision: remediate in place, refactor, replace, isolate behind a compensating control, or retire. Deferring that decision is itself a decision, and usually the most expensive one. It also avoids spending a year making an obsolete application quantum-safe, only to replace it two years later.
Better Understanding Produces Better Estimates
The weakest point in most roadmaps is the effort estimate for legacy applications because it’s only as good as the team’s understanding of the code. When that understanding is thin, schedules are padded, or worse, they aren’t.
Legacy estimates tend to fail in predictable ways. A team sizes the work based on the cryptographic call it can see, then discovers the same routine feeds a batch job, an archive format, and a partner interface that never made it into the inventory. In a wave-based plan, that slip delays every system queued behind it. The answer isn’t more contingency. It’s better information before you make the estimate.
Aspen Codex™ produces current, as-built documentation from existing application assets, giving planners a clear view of dependencies, interfaces, data relationships, and business logic before a wave is scheduled. Aspen’s Warp Drive Engine™ then supports governed modernization for the applications where replacing the cryptography in place isn’t realistic. The result is a roadmap based on what the code does, not what the 2009 documentation says it does.
That visibility pays off twice. Planners sequence waves with greater confidence, and engineers start each migration knowing what depends on the code they are about to change.
A Plan That Can Absorb Change
No roadmap remains unchanged. Vendors will slip, pilots will uncover more work than expected, and guidance will keep evolving. The goal is a risk-based plan, sequenced in waves and based in real-world application knowledge, that the organization can adjust rather than restart when things change. The objective isn’t to preserve the original plan, but the deadline.
In practice, that means a few habits. Revisit priority scores at the end of every cycle. Track vendor commitments as dated dependencies, not assumptions. Keep the inventory current as new applications and acquisitions enter the estate. And report progress as risk reduced (how much long-horizon data is now protected), not just systems completed.
That is the difference between having a list and having a migration program. Inventory creates visibility. Prioritization creates order. The roadmap turns both into executable work.
Going forward, the final post in this series makes the case for modernizing before you migrate, starting with the applications at the front of your roadmap.
Book a Call with Aspen
If your cryptographic inventory is complete (or close) and you’re wondering what to do first, book a call with Aspen to discuss how to turn those findings into a prioritized, realistic migration roadmap. Start with the systems that have the longest path to readiness.
Schedule a discovery chat: https://calendly.com/aspen-ess/aspen-ess-discovery-chat
