How to Estimate Post-Quantum Migration Effort

Ask two competent planners to size the same post-quantum migration and one may come back with 2,000 tasks, the other with 120,000. Both are looking at the same estate. Neither is padding. The whole gap comes from two decisions each of them made silently: what counts as one unit of work, and how much of the surrounding program belongs in the estimate at all.

That is the recurring problem with sizing this particular migration. Cryptography is not a system you can point at and measure. It is distributed across applications, network elements, certificates, firmware, identity infrastructure and vendor products, and most of the schedule turns out to be the work that makes replacement safe rather than the replacement itself. A planner who counts only the replacements will produce a number that is wrong by a factor of three to six.

This article gives you a method: choose a unit, size the unit, apply a ratio test, then adjust for the four conditions that inflate effort in ways a raw task count won’t show. An integrated master schedule, or IMS, is the artifact we’re building toward here: the dependency network of all authorized work, not a checklist of intentions.

The unit you count

Three candidate units are available, and only one of them works.

The cryptographic instance. Every certificate, key, library call and protocol configuration. In a large enterprise these routinely run to six figures, spread across several separately administered PKI and CA stacks. Counting at this level produces a number nobody can schedule against, and it is the assumption behind most accusations that six-figure estimates are inflated. Instances are inputs to triage rather than units of work.

The system. One line per application or network domain. This is what produces the 2,000-task estimate. It hides every dependency that will actually decide the timeline, and it gives a steering committee nothing to hold anyone to.

The remediation package. This is the unit that behaves. A package is a set of assets sharing five attributes: one approved mitigation pattern, one accountable owner, one environment, one dependency chain, and one change window. If two assets differ on any of the five, they belong to different packages, and they will be executed at different times by different people.

The five-attribute rule does the estimating work. Take a bank’s internet-facing API tier. Four hundred services terminate TLS at the same gateway, run under the same platform team, deploy in the same monthly window and depend on the same vendor for the appliance firmware. That is one package, not 400. Now split those services across three regions with three different regulators, three change calendars and two gateway vendors. That is six packages, and the estimate should say so.

Building the package list requires a cryptographic inventory first, and increasingly a CBOM, a cryptographic bill of materials that records algorithms, keys, certificates, libraries and protocol configurations in a machine-readable format. The EU’s coordinated implementation roadmap names standardized cryptographic inventories explicitly. You cannot define package boundaries without one, which is why discovery is a prerequisite of estimation rather than the first thing you estimate.

Sizing one package

Each package carries a repeating task set, and the composition is stable across package types:

library assessment and upgrade, code or configuration change for the new algorithm APIs, certificate profile updates, key rotation procedure, unit test, integration test against dependent systems, performance test under production-like load, security assessment, rollback procedure, deployment plan, staged rollout execution, post-deployment monitoring, evidence capture, and documentation update.

That is 14 named tasks before anything goes wrong. Allow a few more for packages that need extra assurance or a regulator-facing evidence step, use 20 as a planning average, and the arithmetic becomes trivial. An estate that decomposes into 1,200 packages carries roughly 24,000 remediation tasks.

Then stop, because that number is not your estimate. It is the input to the test that follows.

The ratio test

In the large-enterprise model published on PostQuantum.com and in plans built on the same lines, direct remediation accounts for somewhere between 15 and 40 percent of total tasks. Everything else is the system that makes remediation possible and provable.

Apply that to the 24,000 figure. At 40 percent, the full program is around 60,000 tasks. At 15 percent, it is around 160,000. If your draft estimate came in at 26,000, you have costed the cutovers and forgotten the program.

The categories below are drawn from the same published model, which allocates 120,000 tasks across a decade-long horizon for a large telecom operator. Treat the numbers as proportions rather than predictions.

Category	Sample task volume
Remediation execution waves	30,000
Infrastructure foundations (PKI, HSM, KMS, trust stores)	15,000
Testing, interoperability and assurance	14,000
Discovery and living inventory	11,000
Vendor lifecycle and procurement enforcement	10,000
Governance and schedule control	9,000
Cryptographic strategy and pattern library	7,000
Workforce and organizational change	7,000
Operations, monitoring and drills	6,000
Reporting, metrics and audit evidence	5,000
HNDL and TNFL burn-down	4,000
Partner and sector alignment	2,000

Two of those line items need naming properly, since they’re the ones most often left out of a first estimate. HNDL is harvest now, decrypt later: an adversary records encrypted traffic today and decrypts it once a capable quantum computer exists. TNFL is trust now, forge later, the signature-side twin, where long-lived signed artifacts such as mortgages, firmware images and archived contracts become forgeable. Both are active risks rather than future ones, and both generate work in Year 1 that runs parallel to the main migration instead of waiting for it.

The infrastructure line is the other common omission. PKI rebuild, HSM firmware or hardware replacement, trust store updates and certificate profile design have to complete before application waves can start. In most estates that dependency, not the application work, sets the earliest possible finish date.

Four multipliers

Once the base estimate survives the ratio test, four conditions adjust it upward. Each one changes effort per package rather than the number of packages, so they compound.

Operational technology

Industrial control systems, building management, medical devices and physical security equipment carry three to five times the per-asset effort of a standard IT application. The reasons are procedural rather than technical: safety analysis, extended pre-testing, change windows measured in months, and in regulated environments a recertification step with an external authority. In the telecom model, OT generates 15 to 20 percent of total program tasks from a much smaller share of the asset count.

Devices that cannot be upgraded at all don’t disappear from the estimate. They become a decision tree, and each branch is a task chain: gateway deployment, network segmentation, or hardware replacement with procurement lead times of a year or more.

Constrained devices

Low-power IoT is a sizing problem of a different kind. LoRaWAN payload limits vary by region and data rate. At the lowest data rates EU868 allows about 51 bytes per uplink under a 1 percent duty cycle and US915 can drop to about 11 bytes, while higher data rates permit more, up to roughly 222 bytes in EU868. Set that against what a post-quantum handshake puts on the wire. In the X25519MLKEM768 hybrid, the client key share carries an ML-KEM-768 encapsulation key of 1,184 bytes alongside a 32-byte X25519 share, so 1,216 bytes go out where X25519 alone sends 32. ML-KEM is the key encapsulation mechanism standardized as FIPS 203, and the server’s ML-KEM-768 ciphertext coming back is 1,088 bytes. Signatures widen further: an ML-DSA-65 signature, from the FIPS 204 signature standard, runs about 3,293 bytes against 64 for ECDSA P-256.

Estimate these by device family, never by device, and expect the deliverable to be a procurement and installation plan rather than a code change.

Vendor dependency

Vendor work changes schedule position more than it changes effort. A package waiting on a supplier roadmap cannot be sequenced by your team’s capacity, and the estimate should carry that as an explicit constraint. Each critical product line multiplied by each region multiplied by each change window becomes its own dependency chain, with contract updates, joint interoperability testing and an escalation path for suppliers who miss. The escalation path costs tasks whether or not you use it, since isolation, compensating controls and replacement all need designing in advance.

Hybrid operation

Running post-quantum and classical algorithms together is the right transitional approach and it is not a simplification. Every hybrid system needs three tested paths rather than one: classical fallback, post-quantum only, and the combination. Certificate management, monitoring and configuration management all widen. Then a sunset workstream retires the classical component years later. Hybrid adds a layer to the estimate rather than removing one.

From effort to duration

Effort sums. Duration does not, and this is where most estimates lose credibility with a board.

Four constraints stretch a schedule independently of headcount. Absorption capacity limits how much change an engineering organization can accept per quarter. Change windows are fixed by the business, not by the program. Vendor gates arrive when the vendor is ready. Certification cycles, including FIPS validation for new HSM configurations, run on their own calendar.

History gives useful reference points. The SHA-1 to SHA-2 transition took roughly seven years from NIST’s 2011 deprecation to browsers rejecting SHA-1 certificates outright, and that was a single algorithm swap with browser vendors enforcing it. The move from 1024-bit to 2048-bit RSA keys took about a decade. Neither involved new key sizes that break middlebox buffers, and neither touched operational technology. A migration that touches all three, and adds new message sizes on top, belongs in the same decade-scale bracket as those two precedents, and a large estate belongs at the far end of it.

Set that against the regulatory dates. NIST IR 8547 slates quantum-vulnerable mechanisms for deprecation after 2030 and disallowance after 2035. The UK NCSC roadmap expects discovery complete by 2028, high-priority systems migrated by 2031 and everything finished by 2035. The EU roadmap asks member states to begin by the end of 2026, secure high-risk systems by 2030 and complete by 2035.

The estimate’s real job is to show where those two sets of numbers collide, and to name which packages have to move first as a result. A duration model that reports a single end date is less useful than one that reports the first deadline you will miss.

Checking the estimate before you present it

Run these questions against your draft. Each one that fails means the number is too low.

• Does the estimate rest on a package definition you can state in one sentence, with the five boundary attributes named?
• What proportion of total tasks is direct remediation? If it exceeds 40 percent, find the missing enablement work.
• Is discovery costed as a continuing capability rather than a one-time phase? Inventories drift with every release and every new machine identity.
• Are OT and constrained devices estimated separately, with their own multipliers?
• Does every vendor-dependent package carry a named product, a named contact and an escalation branch?
• Is there a Year 1 line for HNDL and TNFL work, running parallel to the main migration rather than queued behind it?
• Does the model include the sunset of hybrid configurations, or does it stop at deployment?

Presenting a number nobody believes

The market has trained executives to expect cryptographic change to look like a patch cycle. The first honest estimate for a post-quantum migration therefore reads as an arithmetic error, and the instinct in the room is to ask what got double-counted.

Present the method rather than the total. Show the unit and why it is the unit. Show the package arithmetic. Show the ratio and what falls outside remediation. Show the multipliers as separate adjustments, each with its reason. A number built in front of an audience survives scrutiny in a way a headline figure never does.

Then scope the ask honestly. Most organizations cannot fund the whole horizon in one round, and they don’t need to. Present a Year 1 slice of 500 or 800 tasks with the full estimate visible behind it, so that early sequencing decisions account for dependencies that surface in Year 5. Building crypto-agility, the ability to swap algorithms without rewriting applications, is the single choice in Year 1 that most reduces the size of Years 4 through 10.

Building the skill

Estimating a program of this shape is a learnable discipline rather than an instinct. It draws on standard schedule practice, an understanding of where cryptography actually lives in an enterprise, and enough technical grounding to know why a 3,293-byte signature changes a network refresh plan.

Quantum Academy’s post-quantum certification programs cover cryptographic discovery, migration planning and program governance for the people who have to build and defend these numbers. You can review the current programs at quantumacademy.com/.

For migration methodology in more depth, the PQC Framework sets out the phase structure this estimate assumes. The full 120,000-task model, including the reasoning behind each category, is documented in the program plan analysis on PostQuantum.com.