What Is a Migration Roadmap?
A post-quantum migration roadmap is a phased, sequenced plan for transitioning an organization's cryptographic infrastructure from quantum-vulnerable algorithms to NIST-standardized post-quantum alternatives. It translates the output of a cryptographic assessment into actionable milestones with owners, dependencies, and timelines.
Roadmaps vary significantly by organization size and complexity. A small software company with a handful of internet-facing services and no hardware dependencies may complete a migration roadmap in months. A large financial institution or federal agency with hundreds of systems, complex supply chains, and regulatory obligations may plan a multi-year program.
Phase One: Cryptographic Inventory
The roadmap begins with cryptographic discovery: building the inventory of every algorithm, key, certificate, library, and hardware cryptographic component in use across the organization. This includes the organization's own systems as well as third-party dependencies, supply-chain software, and vendor services.
The output of Phase One is a Cryptographic Bill of Materials (CBOM). The CBOM records each cryptographic component, the system where it is used, the team responsible for it, and its current state relative to post-quantum readiness.
Phase One typically surfaces surprises: legacy systems with forgotten cryptographic configurations, supply-chain dependencies with no post-quantum roadmap, and hardware components that cannot be updated in place. Identifying these blockers early prevents schedule delays in later phases.
Phase Two: Risk Prioritization
With the CBOM complete, each cryptographic asset is scored for risk. The scoring model considers data sensitivity, data lifetime, HNDL exposure, system criticality, and migration complexity. The result is a prioritized list that drives migration sequencing.
Priority tier assignments guide how the roadmap sequences migration work. Tier 1 systems (protecting long-lived sensitive data) are addressed first. Tier 2 systems are planned in the next phase. Tier 3 systems are scheduled for later phases as higher-priority work is completed.
Vendor readiness assessment is conducted in parallel. For each system in the inventory, the team identifies whether the required post-quantum support is already available from vendors, on their roadmap, or not yet planned. Vendor gaps are surfaced as dependencies that must be resolved before migration can proceed.
Phase Three: Architecture and Vendor Alignment
Architecture decisions are made in Phase Three. The organization selects hybrid or pure-PQC approaches for each system type, determines which certificates to replace, designs the new PKI hierarchy if needed, and defines the sequence of changes required.
Vendor alignment is the most time-consuming part of this phase. Hardware security modules, TLS termination appliances, firmware update systems, and cloud providers must all have support for the target algorithms before migration can be completed. Procurement criteria should be updated to require post-quantum readiness for all new purchases.
Supply-chain coordination requires reaching out to counterparties, ISPs, and API providers whose cryptographic choices affect mutual security. In some industries, this coordination is handled through information-sharing groups or regulatory working groups.
Phase Four: Migration Execution
Execution begins with the highest-priority systems and proceeds through the inventory in risk order. Each system is updated according to the architecture decisions made in Phase Three. Typical activities include enabling hybrid TLS, replacing certificates, migrating code signing, updating HSMs, and reconfiguring VPNs and other protocols.
Testing at each step is required. Interoperability testing validates that updated systems communicate correctly with peers that have and have not yet been updated. Performance testing confirms that new algorithms do not introduce unacceptable latency. Regression testing validates that functional behavior has not been affected.
Rollback plans should be prepared for each system migration. If a migration causes unexpected compatibility failures, reverting to classical algorithms temporarily is preferable to extended downtime. Rollback capability is a deployment requirement, not an afterthought.
Phase Five: Validation and Ongoing Governance
Once migration execution is underway, the organization must validate that updated systems are operating correctly and that no regression has introduced new vulnerabilities. Validation includes cryptographic scanning of updated systems to confirm that quantum-vulnerable algorithms are no longer in use where migration is complete.
Ongoing governance ensures that the migration does not regress. New systems added to the organization must meet post-quantum requirements before deployment. Software updates must preserve post-quantum configurations. The CBOM must be updated as systems change.
Crypto-agility, designing systems so algorithms can be swapped via configuration rather than code changes, is the long-term goal. A crypto-agile architecture can respond to new NIST guidance, newly discovered weaknesses, or changing regulatory requirements without requiring full re-engineering of applications.