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 (less firefighting later, career-relevant skills), not around what’s being taken away or what was wrong before.
- 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” | Frame the migration as a new, valuable skill rather than obsolescence |
| 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.
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.
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.
- Career-relevant skill. Post-quantum cryptography is a scarce, rising skill. Framing the migration as the team learning something valuable, rather than being handed a chore, changes who volunteers.
- 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.
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, and there’s an alignment briefing for it.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.