Enterprise Migration Planning

Why enterprise migration planning matters

A quantum-readiness program is necessary because a cryptographically relevant quantum computer could break public-key systems used in current information systems. CISA, NSA, and NIST state that a successful PQC migration will take time to plan and conduct, and they recommend that organizations develop quantum-readiness roadmaps, conduct inventories and risk assessments, and engage vendors. The urgency is not limited to systems that will be attacked immediately: adversaries may collect information today and attempt to decrypt it later when quantum capability becomes available. [C1, C2]1

The program should be framed as a business transformation and modernization effort. It affects confidentiality, integrity, authentication, key establishment, digital signatures, protocols, applications, hardware, firmware, cloud services, and infrastructure. NIST’s November 2024 document is explicitly an initial public draft, while other cited NIST publications are final; therefore, the roadmap should distinguish settled planning assumptions from items that may change as standards, implementation guidance, and product support evolve. [C9, C10]2

Establish governance and decision ownership

The first planning decision is to establish who owns the outcome. Executive sponsorship should give the program authority to set priorities, resolve cross-business conflicts, approve risk acceptance, and secure funding. A program office should maintain the integrated roadmap, assumptions, dependencies, decision log, milestones, and reporting. Security and privacy risk managers should help prioritize assets that would be most affected by a quantum threat, while IT and OT procurement experts should lead inventory engagement with supply-chain vendors. [C4, C6]1

• Executive sponsor or steering committee: approves ambition, risk tolerance, funding, and exceptions.
• Program office: owns the integrated plan, schedule, dependencies, status reporting, and escalation process.
• Security, privacy, and enterprise risk: defines risk criteria, evaluates exposure and data criticality, and records accepted residual risk.
• Enterprise architecture and cryptography specialists: define target patterns, interoperability requirements, algorithm and protocol assumptions, and technical decision records.
• IT and OT owners: validate service dependencies, operational constraints, safety or availability considerations, and maintenance windows.
• Procurement, supplier management, and legal: obtain vendor roadmaps, contract commitments, support dates, costs, and upgrade or replacement obligations.
• Business and data owners: determine secrecy lifetime, integrity needs, service criticality, retention, and acceptable disruption.
• Internal audit or assurance: tests governance evidence, control operation, exception handling, and progress reporting.

Decision rights should be explicit. For example, the steering committee can decide whether a high-risk legacy system receives replacement funding; the architecture authority can approve a migration pattern; the system owner can approve a maintenance window; and the risk owner can accept a documented temporary exposure. This division prevents a technically correct recommendation from remaining unimplemented because no role owns budget, operational scheduling, supplier escalation, or residual-risk acceptance. The evidence supports cross-functional collaboration, but it does not prescribe a universal organizational chart; each organization should document its own authority model. [C2, C4, C6]13

Build the inventory before committing to a sequence

An inventory is the program’s planning foundation. It should provide visibility into how cryptography is used across IT and OT systems, including network protocols, end-user systems and servers, applications and libraries, services, devices, certificates, key-management arrangements, and supplier-provided components. It should also record the data or service protected, the responsible owner, dependencies, external access, algorithm or public-key use, lifecycle status, upgrade path, and evidence supporting each entry. CISA, NSA, and NIST emphasize that organizations are often unaware of the breadth of application and functional dependencies on public-key cryptography. [C4, C5]1

Inventory discovery should be followed by risk assessment rather than treated as a catalogue exercise. Prioritize assets where a cryptographically relevant quantum computer would create greater harm: information with a long secrecy lifetime, externally accessible datasets or channels, systems supporting critical operations, and technologies that are difficult to upgrade or replace. The assessment should capture both confidentiality and integrity. In an industrial-control context, sensor data may not require strong confidentiality, yet its integrity can be critical because faulty readings or commands can cause control-system failures. [C2, C5, C12]13

Turn risk findings into a budget and business case

Budgeting should follow the inventory and risk assessment, not precede them. Cost categories may include discovery and assessment, architecture and design, application refactoring, testing, certificates and public-key infrastructure, key-management changes, hardware or firmware upgrades, device replacement, supplier support, professional services, training, operational rollout, and contingency for interoperability or performance issues. The evidence specifically calls for vendor engagement about expected migration cost and describes PQC migration as an IT/OT modernization effort. [C2, C6]1

A credible business case should connect each funding request to an asset group, risk, dependency, decision, and measurable outcome. It should distinguish mandatory work from optional modernization, identify benefits of coordinating changes with other upgrades, and show the cost of delay or replacement constraints without inventing quantitative estimates. Physical-infrastructure changes should, where possible, coincide with other maintenance and improvement work. In converged OT/IT environments, conventional IT upgrades that support PQC should be part of business planning. [C13]3

• Fund discovery first where visibility is incomplete; unknown dependencies are schedule and cost risks.
• Reserve separate funding for systems that cannot be upgraded in place or require field service.
• Link certificate, PKI, and key-management work to application and protocol work rather than budgeting them as isolated tasks.
• Include supplier and cloud-provider engagement in the plan, with expected upgrade timing, configuration work, and cost captured as assumptions until confirmed.
• Use stage gates so later funding depends on evidence from pilots, interoperability testing, and operational validation.

Sequence migration by risk, dependency, and readiness

A practical roadmap has discovery, assessment, design, pilot, staged deployment, and retirement or closure activities. The order should be risk-based and dependency-aware. Long-secrecy data, externally exposed public-key channels, high-impact authentication, and critical OT integrity paths generally deserve early assessment and, where feasible, early remediation. However, a high-risk system may depend on a supplier, protocol, certificate hierarchy, device, or implementation that is not yet ready. The roadmap should therefore record both the desired priority and the blocking dependency rather than silently moving the system to a later date. [C2, C7, C8]13

Migration may require a period in which classical and PQC mechanisms operate simultaneously. The NCSC evidence describes staged approaches in which protocols such as TLS and IKE negotiate certificates after both communicating parties have been upgraded, or in which a new PQC root of trust cross-signs an older one. These choices require case-by-case security assessment. In general, quantum-secure authentication is not achieved until PKI migration is complete and traditional certificates have expired or been revoked. [C7]3

Sequencing must also account for implementation maturity. Robust, standards-compliant implementations of algorithms and protocols will not all be ready at the same time, and global cryptographic infrastructure will take years to become fully PQC-ready. NIST’s initial public draft also notes that applications and services may require changes to key sizes, algorithm performance, protocols, libraries, code, tests, and sometimes user interfaces. These are planning dependencies, not merely deployment tasks. [C8, C10]2

Plan for IT, OT, cloud, and legacy constraints

OT and IT planning cannot be separated where networks, identities, remote access, sensors, and control systems converge. In an industrial-control environment, OT and IT zones may be separated by a DMZ firewall, while remote internet logins require secure authentication. Wireless field devices and sensors introduce additional integrity concerns, and internet-connected industrial IoT devices can provide an entry point into control networks and onward into the IT zone. These characteristics should affect ownership, risk scoring, test design, maintenance scheduling, and escalation. [C13, C12]3

Legacy and embedded devices require a dedicated treatment path. They may be resource-constrained, unupgradeable, difficult to service, embedded in larger products, unsuitable for replacement, dependent on proprietary communications, or based on protocols that are not yet PQC-compatible. The plan should identify these devices early, document their operational and security consequences, obtain supplier information, and decide whether to upgrade, isolate, replace, retire, or manage the residual risk. The evidence does not establish one universal compensating control, so the decision must remain system-specific. [C12]1

Cloud-hosted products should be included in supplier governance. Organizations should ask cloud service providers for their quantum-readiness roadmaps and, once standards and product support are available, clarify how PQC will be enabled through configuration changes or application updates. The same discipline applies to commercial off-the-shelf products: record when and how each vendor expects to deliver updates or upgrades and the associated expected cost. [C6]1

Include key, certificate, and control-lifecycle decisions

A migration plan is incomplete if it tracks algorithms but not keys, certificates, metadata, and lifecycle operations. NIST describes four key-management phases: preoperational, operational, postoperational, and destroyed. Key metadata can include identity, type, cryptoperiod, usage period, and authorization-related information; it remains important to application and protocol behavior even though it is not itself part of the cryptographic algorithm. These lifecycle states should be represented in discovery, test cases, operational procedures, archival decisions, revocation, and retirement evidence. [C20, C21]13

Every roadmap stage should have an entry criterion, accountable decision owner, evidence requirement, and exit criterion. Examples include: inventory coverage accepted by the program office; risk ranking approved by the risk owner; supplier readiness confirmed or recorded as an assumption; interoperability and performance tests passed; operational rollback or recovery rehearsed; certificates issued and old certificates managed; and residual risk formally accepted or closed. This gate-based approach preserves decision traceability while allowing different systems to progress at different speeds. [C7, C20]13

Measure progress and re-plan deliberately

Progress reporting should show more than the number of systems assessed. Useful measures include inventory coverage, percentage of assets with an accountable owner, proportion with known cryptographic dependencies, risk-ranked assets with approved treatment, supplier responses received, migration patterns tested, certificates or keys covered by lifecycle procedures, and systems that have passed operational validation. Measures should be accompanied by open decisions, blocked dependencies, assumptions, exceptions, and budget variance. [C4, C6, C20]1

Re-planning is expected because standards, implementation guidance, product support, and infrastructure readiness evolve. The cited materials include both final documents and the NIST IR 8547 initial public draft; the draft status matters when baselining technical requirements. Organizations should maintain versioned assumptions, review vendor and standards developments, and revisit sequencing when a dependency changes. A current roadmap is therefore a controlled decision record, not a one-time schedule. [C9, C10, C17]1

Conclusion

Enterprise migration planning succeeds when PQC is governed as a cross-functional modernization program with explicit ownership, evidence-based prioritization, realistic budgets, supplier accountability, and staged decisions. Start with inventory and risk, include IT, OT, cloud, applications, certificates, keys, and legacy devices, then sequence work around secrecy lifetime, operational impact, external exposure, dependencies, and implementation readiness. Preserve uncertainty where the evidence is provisional, test coexistence and lifecycle operations, and re-plan as standards and products mature. [C1, C4, C7, C9]13