up:: The Human & Organizational Side MOC

Change Management for Cryptographic Migration

Change management for a cryptographic migration is the discipline of getting people to actually adopt the change, and it stalls more post-quantum programs than any technical problem. The cryptography is bounded and largely solved. The human system around it, the engineers who have to do the work and quietly fear what it means for them, is where a program with a flawless roadmap sits for years without moving. The most reliable way through is counterintuitive: start with the smallest, most completely reversible moves you can find, because reversibility is what defuses the fear.

The short version:

• Change management is the true bottleneck of the quantum transition, not the algorithms.
• Engineers resist quietly, through delays and deprioritization, because a migration can feel like it threatens hard-won expertise, exposes gaps, and competes with the delivery work they’re actually measured on.
• The move is to start with a few completely reversible first steps, so nothing the team tries can strand them, which is what lowers the stakes enough to act.
• Frame the change around what developers gain, choosing the gain carefully: the durable skill is running a migrating estate rather than mastery of any one successor algorithm.
• Present it as the new baseline, not a crisis, and make it visible and sustained over the multi-year program.

Think of it like renovating a house people are still living in. The construction is the easy part to plan. The hard part is that the residents are anxious about the disruption, unsure what the place will feel like afterward, and quietly worried they’ll lose something they liked. You get their buy-in not by handing them the blueprint, but by starting with a small change they can undo, so they learn the renovation won’t strand them.

Why is change management the real bottleneck of a post-quantum migration?

Because the constraint is people, not math, and most programs mis-diagnose it. A team can choose ML-KEM, design the hybrid rollout, and write a beautiful roadmap in weeks. Then nothing happens, because the roadmap assumed the humans would simply execute it. They won’t, not out of malice, but because the migration competes with everything else they’re measured on and carries a quiet emotional weight the plan never accounted for. Every firm has the technical arm; almost none treat the human adoption as real work with its own method, which is exactly why so many programs stall at the point where a plan has to become motion. Naming the human system as the bottleneck, and resourcing it deliberately, is most of the fix.

Why do engineers resist a cryptographic migration?

Rarely in the open, and rarely because they think it doesn’t matter. The resistance is quieter and more human than disagreement, and it has specific sources worth understanding, because each one points to a remedy:

• It can feel like a threat to hard-won expertise. Cryptography is specialized knowledge people spent years earning. A migration can read as “the thing you’re expert in is now obsolete,” which is a quietly destabilizing message to send someone.
• It exposes gaps. “I’ve never deployed a KEM” is uncomfortable to admit, so the discomfort turns into avoidance and requests for more analysis rather than a first attempt.
• It can feel like an admission the old design was wrong. Migrating the cryptography you built or chose can land as a verdict on your past judgment, which nobody volunteers for.
• It competes with delivery. Engineers are measured on shipping features, and the migration is invisible work with no immediate payoff, so it loses every prioritization fight it’s forced into.

What the resistance is really about	How it shows up	What defuses it
A threat to hard-won expertise	”Let’s not rush this”	Offer authorship of the new standard, and name estate-moving as the durable skill
Fear of exposing a gap	Endless requests for more analysis	A low-stakes reversible first move where a mistake is cheap and private
Feeling it admits the old design was wrong	Quiet deprioritization	Present it as the new baseline, not a verdict on past judgment
Competing with delivery KPIs	The pilot stays perpetually next-quarter	Make the work visible and recognized like anything else that’s measured

Because the resistance is emotional and quiet, it shows up as friction rather than refusal: “let’s wait for the standards to settle,” a discovery task that never quite gets scheduled, a pilot that stays perpetually next-quarter. A hundred of those small delays are what a stalled migration is actually made of.

How do you tell a real objection from a displaced one?

This is the most important judgment in the discipline, and getting it wrong is expensive in both directions. In a security engineering culture the difficulty rarely arrives as feelings. It arrives as well-formed technical objections: the assumptions behind the new primitives have been studied for less time than factoring, parameter sets may change again, migrating introduces more risk than it removes. Every one of those is a position a competent person could hold on the merits, and every one is also what displaced loss sounds like coming from an engineer.

The sorting property is falsifiability. Ask what the objector would need to see for this to look like the right call. A real objection names a condition, and a displaced one cannot, with the goalposts moving when the stated condition is satisfied. The full test, including what to do with each answer, is in The Falsifiability Question.

The corollary matters as much. Some resistance to a cryptographic migration is substantively correct, and a program with no category for that will treat a well-founded engineering warning as a confidence problem to be managed. Parts of an embedded estate genuinely cannot be updated, some vendors will not ship in time, and the inventory has defeated multiple serious attempts at organizations larger than yours.

What are the three smallest completely reversible moves?

The most effective opening to a cryptographic migration is a handful of moves small enough and reversible enough that the team can try them with no fear of a one-way door. Reversibility is the active ingredient. When a first step can be undone with a config change, the anxiety that drives the resistance has nothing to grip, and people act.

What makes a move qualify:

• It’s genuinely reversible. You can turn it off and return to exactly where you were, with a config flag, not a rebuild or a migration back.
• It’s low-stakes. It touches one internal, non-critical system rather than a customer-facing crown jewel, so a mistake is cheap and private.
• It builds real competence. The team ends it knowing something they didn’t, which is what converts fear of the unknown into ordinary engineering confidence.

Concrete examples of a reversible first move:

• Turn on a hybrid handshake for one internal service. Enable hybrid key exchange between two internal systems where classical stays negotiable, so it falls back cleanly and flips off in one line.
• Run a discovery pass on a single system. Inventory the cryptography of one bounded application, producing a small piece of the eventual CBOM and a first taste of what discovery actually involves.
• Enable a post-quantum-capable library without switching it on. Upgrade to a library or provider that speaks the new algorithms (many mainstream stacks already do) and leave the classical path active, so nothing changes in production while the capability quietly arrives.

None of these commits the organization to anything. All of them teach the team that the migration is a series of ordinary, undoable steps rather than a cliff. Once the first reversible move lands without incident, the second is far easier, and the program has motion it didn’t have before.

Why does reversibility work, and when does it fail?

It works because whether someone acts depends on who absorbs the loss if it goes wrong, rather than on how persuasive the case for acting was. Reversibility moves the downside off the individual, so the fear has nothing left to hold onto. That is the whole mechanism, and knowing it tells you when the move will fail.

It fails when the step is reversible in the system and permanent for the person. Approving a post-quantum design stakes professional judgment on primitives whose long-term security is a considered bet on public analysis, and the arithmetic facing that individual is unforgiving: approving carries a small chance of a career-defining error, while declining to approve carries no attributable risk at all, because harm from harvested traffic is silent and nobody is ever named in it. Inaction in security is almost never attributed and action always is, so waiting is individually rational and collectively expensive.

Three moves lower the personal cost so the config-level reversibility can do its job:

• Make the sign-off institutional. A decision recorded as the organization’s carries a different weight than one attached to a person’s name.
• Record decisions as revisable, with named reconsideration triggers. That is what crypto-agility buys, and it is worth stating in those terms rather than only as an architectural property.
• Frame hybrid as the bet that does not have to be won. Classical still stands behind it, which is precisely why the construction exists.

How do you frame it so developers actually want it?

Lead with what they gain, in their own terms, rather than with the threat or the obligation:

• Less firefighting later. Crypto-agility means the next algorithm change is a config swap instead of an emergency project. Engineers who have lived through a rushed migration understand immediately why building for the next one is worth it.
• A durable skill rather than a replacement one. Be careful which skill you name here, because the obvious answer is the wrong one. Framing the gain as expertise in a specific successor algorithm offers someone a replacement for what they are losing, and it points them at an asset that depreciates the next time a parameter set changes. The expertise that holds is the ability to run a migrating estate: knowing where cryptography lives across the organization, being able to move it safely, and treating no primitive as permanent. Plenty of engineers will learn the new algorithms from documentation, and very few can move a real estate, which is what makes it worth having and what makes it survive the migration after this one.
• Reduced future risk to their own systems. The migration protects the things they built and are on call for. It’s their systems that stop being a liability, which is a message that lands differently than a compliance mandate.

The reframe from “we have to do this because of a deadline” to “this makes your work more durable and your skills more valuable” is what turns quiet resistance into ordinary engineering.

How do you make it normal instead of heroic?

People adopt a change presented as the new baseline far more readily than one framed as a crisis response. A few moves make it feel routine:

• Present it as the standard, not the exception. “This is how we do key exchange now” invites far less resistance than “we’re launching a major migration initiative.”
• Let small wins compound. Each reversible move that lands without drama becomes evidence that the next one is safe, so momentum builds from proof rather than exhortation.
• Grow champions from the early movers. The engineer who ran the first hybrid handshake becomes the person others ask, which spreads competence horizontally instead of pushing it down from management.

How do you sustain it over a multi-year program?

A post-quantum migration is a marathon, and the early energy fades long before the work is done, so sustaining it is its own task:

• Keep it visible. Report progress on the same cadence as any executive initiative, so it doesn’t quietly slip back to being nobody’s job.
• Set a rhythm the organization can hold. A steady, predictable pace beats a burst of activity followed by a stall. Change fatigue is real, and a sustainable cadence is what outlasts it.
• Recognize the invisible work. Migration progress rarely shows up in a demo, so it needs deliberate recognition, or the people doing it drift back to work that gets noticed.

Common misconceptions

• “If we mandate it, they’ll do it.” A mandate produces compliance-shaped delay, not adoption. The resistance is emotional, and an order doesn’t address the fear underneath it.
• “Engineers will resist because they don’t understand the threat.” Usually they understand it fine. The resistance is about expertise, exposure, and competing priorities, so education alone won’t move it.
• “Change management is soft, secondary to the real technical work.” It’s the primary bottleneck. The technical work is the part that was always going to get done once people actually started.
• “Start with the most important system to show we’re serious.” Backwards. Start with the least important, most reversible system, so the first attempt is cheap, private, and safe. Confidence is built on small undoable wins, not on high-stakes debuts.

Questions people ask

How long before we see movement? Weeks, if the first move is genuinely reversible and genuinely small. Programs that see nothing for months have usually started with a system important enough that the first attempt carries real consequences.

Our engineers say they support it and nothing happens. What is that? Agreement without motion is the ordinary shape of this problem. Support costs nothing to state, and the work still competes with everything the team is measured on. Check whether migration work is carved out of the delivery and incident numbers before concluding anything about attitude.

Is this just internal marketing? The opposite. Campaigns, branded material, and enthusiasm sessions consistently read as marketing for a program that has delivered nothing, which is worse than staying quiet. What moves people is a small completed thing, an honest account of the cost, and a part to play.

What if the resistance is coming from one senior person? Give them adversarial review of the migration itself. Somebody has to attack the hybrid design, the downgrade paths, and the parameter choices, and skepticism about new primitives is the qualification for that role rather than an obstacle to it.

Do we need a change-management consultant? For the generic version, no, and it tends to be dismissed in an engineering culture anyway. The same material lands when it is framed as migration risk and human factors, delivered by someone who has held cryptographic material themselves.

How do we know it is working? Count what has been decommissioned. Adoption metrics that only go up are dominated by the easy estate and can climb for years while nothing is finished.

What if leadership will not resource this? Then it is not resourced, which is the ordinary outcome, because this work produces no artifact that competes with a Gantt bar. The way through is to attach it to something that does, per Declaring Classical Cryptography End-of-Life.

Go deeper

• Declaring Classical Cryptography End-of-Life: the decision that has to be made before any of this works, and why an approved roadmap without it produces no motion.
• Operating Through a Long Hybrid Period: the decade the team spends between the ending and any arrival, and what makes it survivable.
• Why Post-Quantum Migrations Stall: the wider anatomy of a stall.
• Cryptographic Ownership: who holds the authority that makes any of this actionable.

---

The precedent

With Odysseus gone twenty years, a hundred suitors occupied Penelope’s house and pressed her to choose one of them. She told them she would choose as soon as she had finished weaving a burial shroud for her father-in-law Laertes, which was a duty none of them could argue against. She wove at the loom every day, and every night by torchlight she unpicked the day’s work. Three years passed this way. The suitors had no complaint available to them, because the work was visibly underway the entire time. It ended only when one of her maids told them what she was doing.

Homer, Odyssey II.93–110 and XIX.137–156

The moral: someone who cannot refuse openly will produce work that is always in progress and never finished.

Engineers almost never refuse a cryptographic migration. Refusing is costly and it requires saying something out loud that is difficult to say, usually that the change threatens hard-won expertise or reads as a verdict on a system they built. What comes back instead is a request for more analysis, a dependency that has to be resolved first, and a well-argued case for waiting until the standards settle. Each of those is defensible on its own. Three years of them is a shroud. Penelope was not being difficult and she was not lying about the weaving. She had been handed a question she could not answer safely, and this was the only answer available to her.

---

Everything here is the map, given freely. When your team needs the human side of the transition run as deliberately as the cryptography, so a roadmap actually turns into motion, that’s the work I do.

Last verified 2026-08-17 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.