up:: The Human & Organizational Side MOC
The Capacity Question
The capacity question is a single check on a post-quantum roadmap: how much cryptographic change has this organization actually absorbed per year, measured from its own history, and is the plan written above that number? The answer is knowable from evidence the organization already holds, it takes about a day to establish, and it is almost never asked. Roadmaps are built backwards from a deadline instead, which produces a plan that misses its first date, then its second, and teaches everyone watching that the program can safely be discounted.
The short version:
- Capacity for cryptographic change is measurable from your own last 3 to 5 years, and it is a smaller number than most plans assume.
- A roadmap written above capacity fails on arithmetic rather than on effort, so adding urgency to it changes nothing.
- The first missed date is expensive out of proportion to its size, because it sets the rate at which people discount everything the program says afterward.
- Capacity is shared. A migration running alongside a cloud move, a vendor consolidation, and a security reorganization is drawing on the same pool.
- The response to a plan above capacity is a narrower target rather than a longer list, and narrowing is a decision only leadership can make.
Think of a rail network planning to replace signaling across 400 miles of track. Engineering can tell you how long one mile takes. What determines the schedule is how many miles this particular network has actually replaced per year for the last decade, given its access windows, its inspection regime, and the fact that trains have to keep running. A plan written from the per-mile figure rather than from the historical rate is a plan that will be revised every year until it matches the rate.
How do you measure capacity from evidence you already have?
By counting completed cryptographic changes in the recent past rather than estimating future ones.
The evidence exists and is rarely assembled. Look back 3 to 5 years and count what actually landed end to end, including the decommissioning:
| Evidence source | What it tells you |
|---|---|
| TLS version upgrades across the estate | How long a protocol-level change takes from decision to the old version being refused |
| Certificate authority migrations or hierarchy changes | Capacity for change in the most conservative part of the estate |
| Cipher suite deprecations actually completed | Whether the organization can remove an option rather than add one |
| Library or framework migrations touching cryptography | How long a dependency change takes when it is genuinely estate-wide |
| The last forced cryptographic migration, such as SHA-1 retirement | The closest available analogue, and the one people still remember |
Two numbers come out of it. The first is throughput, meaning how many crypto-touching changes complete per year. The second is lead time, meaning how long one change takes from decision to the old path being retired. Lead time is usually the surprise, because organizations remember when a project started and forget when the last dependent was finally moved.
Why is a roadmap above capacity worse than a slow one?
Because it converts a scheduling problem into a credibility problem, and credibility is much harder to rebuild.
A plan written above capacity misses its first milestone for structural reasons, and the organization reads that as a program that overpromises. The second miss confirms it. By the third, teams have priced the roadmap into their planning as optional, and that discount does not lift when the plan is later corrected, because the correction arrives from the same source that produced the first two misses.
There is a compounding effect underneath it. A workforce that has watched initiatives dissolve is calibrated rather than pessimistic. Their disbelief is evidence-based, and treating it as a morale problem to be addressed with better messaging will end your standing with exactly the people whose cooperation the migration requires. The only thing that moves a calibrated estimate is a completed thing, which is why one finished crossing outperforms any amount of re-planning.
What competes for the same capacity?
Everything else touching the same systems and the same people, which is usually more than the plan accounts for.
A migration running at the same time as a cloud migration, a vendor consolidation, an identity provider change, and a security reorganization is not running alongside them. It is queueing behind them for the attention of the same architects, the same change windows, and the same risk committee. People absorb a surprising amount of change when it is coherent and part of one story, and small unrelated changes arriving together set them back further than a single large one would.
This is the practical form of the question for a sponsor: of the initiatives currently in flight, which ones touch the systems this migration touches, and has anyone added up the total? The answer is frequently the reason the roadmap was unachievable, and it is a scheduling decision available to leadership rather than a constraint anyone has to accept.
Why won’t your vendor tell you about this?
Because capacity is the variable that determines whether a deal is a 3 year program or a 10 year one, and the shorter number closes.
A vendor is quoting the work their product performs, which is genuinely fast. The gap between that and the elapsed time in your organization is made of change windows, dependency mapping, regulatory approvals, teams with other commitments, and the parts of the estate nobody owns. None of that is in the product demo and none of it is dishonest to omit, and the buyer who does not ask ends up with a plan built on the vendor’s throughput rather than their own.
The same applies to peer benchmarks. An organization that migrated in 18 months usually had a smaller estate, a modern one, or an existing crypto inventory, and the number travels between organizations far more easily than the conditions that produced it.
What do you actually do about it?
- Establish the two numbers before the roadmap is signed. Throughput per year and lead time per change, taken from your own last 3 to 5 years. A day of work, and it changes what everyone is arguing about.
- Compare the plan against them out loud, in the room. A roadmap requiring 4 times the historical rate is not a stretch target, it is arithmetic that will be corrected by events, and saying so early is far cheaper than discovering it in year 2.
- If the plan exceeds capacity, narrow the target rather than extending the list. Crown jewels moved, long-retention data prioritized, the rest inventoried, agility built so the next move is cheap, and the never-migrating estate documented as carried residual risk. That is achievable and demonstrable, and it states plainly what full migration would require.
- Or raise capacity deliberately, and name what it costs. Dedicated headcount, protected change windows, or removing a competing initiative from the queue. Capacity can be increased, and it is increased by decisions rather than by emphasis.
- Recheck annually. Capacity moves as the organization learns, and a program that has completed 2 crossings genuinely has a higher rate than the one that had completed none.
Common misconceptions
- “Capacity is just a resourcing question.” Headcount is one input. Change windows, risk approval cadence, dependency depth, and how many other initiatives are in flight usually bind harder, and none of them is fixed by hiring.
- “The regulatory deadline sets the schedule.” A deadline sets an obligation. Capacity sets what will actually happen, and where the two disagree the deadline produces reporting rather than migration. Knowing the gap early is what allows a scope conversation while there is still time to have one.
- “Our estate is modern, so historical capacity does not apply.” The modern part of the estate is the part that moves fastest and carries the least risk. Historical capacity is mostly a measurement of the difficult remainder, which is where the schedule is decided.
- “Measuring this gives people an excuse to go slow.” It gives everyone a shared, evidence-based number to plan against. Programs go slow when the plan was never achievable and nobody said so.
- “We can just add people.” Cryptographic change is gated by review, testing, and dependency knowledge more than by implementation hours, and new people arrive without the estate knowledge that makes the work safe.
Questions people ask
What if we have no history of cryptographic change? That is itself the answer, and an important one. An organization that has completed no crypto-touching migration in 5 years has an unmeasured capacity and should assume it is low, then prove otherwise with one bounded crossing.
How does this fit with the deadline we are given? It tells you the size of the gap, which is the input to a scope conversation. A gap discovered in year 1 has options available to it, and the same gap discovered in year 3 has almost none.
Who should hear this number? The sponsor and the board, early. It is one of the few migration figures that is board-legible without translation, and a board that has heard it will read a multi-year timeline correctly rather than as underperformance.
Does this let us off the hook for the hard parts? The opposite. Naming capacity is what forces the prioritization conversation about which parts genuinely have to move first, which is the conversation an over-ambitious roadmap avoids by pretending everything moves.
Can capacity be raised quickly? Somewhat, and by decisions rather than by exhortation: removing a competing initiative, dedicating a team, or widening change windows. Each has a price, and naming the price is the point.
How does this relate to the lead-time sort? They pair. The Lead-Time Sort tells you what to start first because it takes longest, and the capacity question tells you how many such things can be in flight at once.
Go deeper
- The Lead-Time Sort: sequencing the work by how long each item takes to move.
- The Turned-Off Test: the completion measure that shows whether capacity estimates were right.
- Why Post-Quantum Migrations Stall: the wider anatomy of a stall, including the non-capacity causes.
- The Three Numbers: the board-facing figures this one informs.
Everything here is the map, given freely. When your team needs capacity established from your own history and the roadmap rebuilt against it, that’s the work I do.
Last verified 2026-08-19 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.