up:: Migration Architecture MOC

The Inventory-First Cost Build

The inventory-first cost build is the order you use to size a post-quantum migration budget: fund and run discovery first, then price each cost driver against what the inventory actually found, then add the lines a shallow estimate leaves out, and only then frame the total against what it protects. It’s the same count-then-price method the U.S. government used to reach its one published figure, and it exists because a migration cost scales with an estate nobody has mapped yet, so the number has to be built from the estate rather than looked up in a table.

The short version:

1. Build the number in one direction: count first, price second. Discovery gets funded before any other line, because every other line is priced off what it finds.
2. Price five drivers against the inventory, which are engineering and replacement, legacy hardware (usually the largest), the certificate and root-authority program (usually the longest), vendor and third-party effort, and program governance.
3. Add the three lines almost every estimate forgets, which are procurement cycle time, the parallel crypto-agility project, and the dual-stack period when you run and pay for both cryptographies at once.
4. Frame the total against what it protects, as one investment figure, and phase it across budget cycles by starting before a deadline compresses it into one.
5. The negative test rides inside the framework: anyone who hands you a firm per-organization number before seeing your inventory is selling you a number rather than measuring your cost.

Think of it like getting an honest bid to renovate an old house. A contractor who names a price over the phone, before walking the property, is guessing, and the guess is worth what you paid for it. The real bid comes after the walkthrough: he opens the walls, counts the rooms, finds the knob-and-tube wiring the last owner never mentioned, and prices the job room by room from what he saw. Then he adds the lines a homeowner never thinks of, which are the permits, the inspections, and the months you pay to rent somewhere else while both kitchens exist at once. The inventory-first cost build is that discipline applied to cryptography: walk the estate, price what you found, and remember the lines that live off the visible page.

What is the inventory-first cost build?

The inventory-first cost build is a sequencing rule for producing a defensible migration budget, and the sequence is the whole framework. Almost none of the cost is the cryptography, because ML-KEM, ML-DSA, and SLH-DSA are free, open NIST standards whose reference code costs nothing to download. The bill is the human work wrapped around them: finding every place cryptography lives, replacing each instance without breaking what depends on it, and coordinating the teams and vendors who touch it. The algorithm swap on a modern system you control is the easy 20%. Finding it everywhere and rolling it out safely across an estate you never fully mapped is the 80%, and the 80% is what the number has to capture.

Source: Office of Management and Budget, “Report on Post-Quantum Cryptography,” July 2024, OMB PQC Report.

The build runs in four moves, in this order:

1. Fund discovery first. Every other line is priced off what the inventory finds, so the inventory is the first funded phase and its output is the input to everything after it.
2. Price each driver against the inventory. Take the five cost drivers and weight each one against what discovery actually surfaced in your estate, rather than against a generic rate card.
3. Add the three forgotten lines. Procurement cycle time, the parallel crypto-agility project, and the dual-stack period are where shallow estimates quietly blow up, so they go in explicitly.
4. Frame and phase. Present the total as one investment figure weighed against what it protects, and spread it across budget cycles by starting early enough to have that option.

The framework applies whenever someone needs a migration figure they can defend line by line, which is a budget request, a board memo, or a vendor negotiation. It does NOT apply as a shortcut to skip discovery: the one thing the build refuses to do is produce a number before the estate has been counted. And it stops where the firm apparatus begins. The public method is the order and the driver list. The weights each driver carries, the multipliers, and the per-driver estimation models are the engagement, because those are what turn a defensible structure into a defensible dollar figure against a specific estate.

Why build the number the way the government built its $7.1 billion?

Because the one authoritative public figure was produced by exactly this method, which makes it the worked precedent, rather than a number to copy. The projection inside OMB’s report is ONCD’s, and it puts that migrating priority federal civilian information systems, other than national security systems, to post-quantum cryptography between 2025 and 2035 would cost approximately $7.1 billion in 2024 dollars. That figure is a scale anchor for an enormous, decade-long, whole-of-government program, and it carries the government’s own stated “high, but expected, level of uncertainty” because it was built early while agencies were still inventorying.

Source: Office of Management and Budget, “Report on Post-Quantum Cryptography,” July 2024, OMB PQC Report.

The figure never came from a formula. It came from a reporting loop that ran count-then-price at national scale. OMB M-23-02 directed every federal civilian agency to submit a prioritized inventory of its quantum-vulnerable cryptographic systems (§II.A), and then, no later than 30 days after each inventory, to submit an assessment of the funding required to migrate those systems (§III). The government-wide $7.1 billion is the aggregate of those agency funding assessments. Inventory first, then cost the inventory, then sum. That is the identical two-step any large organization runs to size its own bill, one estate instead of a whole government.

Source: Office of Management and Budget, “Migrating to Post-Quantum Cryptography,” Memorandum M-23-02, November 18, 2022, OMB M-23-02, §II.A and §III.

The precedent matters for a second reason, which is defensibility. The M-23-02 inventory carries a nine-element schema per system, down to the specific algorithm, its key or module length, the hosting environment, and how long the data must stay protected. A number sitting on top of that kind of inventory survives an auditor asking where it came from, because each line traces to a counted, characterized system. The lesson to lift is the shape, not the sum: the federal figure is proof that the way to price a migration is to count it first, and it is useless as a per-organization number because it covers a decade across the entire civilian government and cannot be divided down by any ratio.

How do you price each cost driver?

You price each driver against what discovery told you about your own estate, and the mix of drivers is what makes two organizations of the same size cost wildly different amounts. The table names each driver, what the inventory has to tell you before you can price it, and why the driver is easy to miss when someone estimates from a diagram instead of from a count.

Cost driver	What the inventory tells you	Why it’s easy to miss
Discovery and inventory	The size and sprawl of the estate, and how much cryptography was undocumented until you looked	Treated as overhead rather than the phase that prices every other line
Engineering and replacement	How many systems you build and control yourself, where the swap is a config change or a code change	The visible, easy 20%, so estimates anchor on it and undercount the rest
Legacy and hardware replacement	How many devices bake cryptography into firmware that can’t be updated and has to be replaced outright	Usually the single largest line, and invisible on any architecture diagram
The certificate and root-authority program	The depth of the PKI hierarchy and how many systems trust each root	Usually the longest line, because rebuilding the trust hierarchy touches everything and can’t be rushed
Vendor and third-party effort	How much of the estate moves on someone else’s roadmap rather than yours	Priced as your labor when much of it is waiting, contract leverage, and dependency risk
Program and governance	The number of teams involved and the years of coordination a named owner carries	Feels like a soft cost, so it’s dropped, and an unowned program stalls after it’s funded

Three of these drivers deserve a closer look, because they are the ones a shallow estimate reliably gets wrong.

1. Legacy hardware is a significant portion of the estimate. The U.S. government’s own report names systems that “could not accommodate new cryptographic systems” as the costly category, giving hardwired hardware or firmware as one of two examples alongside systems that “lack the capacity to accept replacement cryptographic algorithms,” and says the cost to replace that whole category “constitutes a significant portion of the overall estimate”, because they often can’t be updated and the device gets replaced outright. Discovery is what tells you how many of these you have, and until it does, this line is a blank that a rate-card estimate silently prices at zero.

Source: Office of Management and Budget, “Report on Post-Quantum Cryptography,” July 2024, OMB PQC Report.

2. The certificate and root-authority program is usually the longest line. Rebuilding a certificate hierarchy your whole estate depends on carries estate-wide blast radius: every system that trusts a root has to move with it, in an order that can’t be reversed mid-flight. Length is cost here, because a line that runs for years consumes governance, testing, and dual-running the entire time.

3. Vendor effort scales with how much you don’t control. The who-controls-it answer in your inventory decides this line. Rows a vendor controls move on a vendor’s schedule, and the moment to price and shorten that schedule is at procurement and renewal, which is a cost driver dressed as a calendar problem.

The pattern underneath the table is the same one the 20/80 split names: the drivers a quick estimate forgets, which are legacy-hardware replacement, the certificate program, vendor coordination, and multi-year governance, are usually the ones that dominate the real bill.

Which three lines does almost every estimate forget?

There are three cost lines that live off the visible page, so they get left out of nearly every first-pass estimate, and each one is where budgets quietly blow up. Put them in explicitly:

1. Procurement cycle time. The leverage to move a vendor’s price and timeline exists at contract renewal and almost nowhere else. An estimate that assumes vendors will move on your schedule, rather than on their renewal calendar, has mispriced both the timeline and the negotiating position, and the cost of that shows up later as premium pricing against a deadline.
2. The parallel crypto-agility project. Crypto-agility is the up-front investment that keeps the next algorithm change a configuration swap instead of another full multi-year program. Leaving it out makes this migration look cheaper on paper and guarantees the next one costs the same as this one. The agility test is how you find which systems need that investment and which already have it, so this line can be priced against the estate rather than guessed.
3. The dual-stack period. For a stretch of the migration you run and pay for both the old cryptography and the new one at once, because you can’t turn the classical algorithm off until everything that depends on it has moved. Those overlap years are a real operating cost, and an estimate that models an instant cut-over prices zero for a period that in practice runs for years.

The reason all three vanish from a first estimate is that none of them appears in the part of the work you can see. Engineering effort is visible, so it gets counted. Procurement lead time, the agility investment, and the years of dual-running are consequences of the migration rather than tasks inside it, so they hide until the budget is already set and then arrive as overruns.

What does the build look like on a real estate?

Run the method on a generic mid-size organization, driver by driver, and watch line items appear from the inventory. The point of the worked example is the method, so it produces line items and their relative weight, never a fabricated total. No honest total exists without the estate’s real numbers behind it, which is the entire argument of the framework.

Start by funding discovery. It comes back with a picture: a few dozen self-built services on modern stacks, one deep PKI with an internal root that signs across the whole estate, a fleet of operational devices with cryptography baked into firmware, a handful of critical SaaS platforms whose internals nobody can see, and one identity provider whose token-signing key never made it onto the certificate list. Now price each driver against that picture.

Driver	What discovery found	How it prices
Engineering and replacement	A few dozen modern, self-built services where the swap is a config or library change	A moderate, well-understood line, the easy 20%
Legacy and hardware replacement	A firmware-embedded device fleet on a multi-year refresh cycle	The largest line, because the units get replaced, not reconfigured
Certificate and root-authority program	One deep internal PKI with estate-wide trust dependencies	The longest line, running for years and touching everything downstream
Vendor and third-party effort	A handful of vendor-opaque SaaS platforms on their own roadmaps	Sized by dependency and renewal timing, priced at procurement
Program and governance	Six teams that have to coordinate over the life of the program	A standing multi-year line, not a one-time cost

Then add the three forgotten lines to the same estate: the procurement cycle time to get post-quantum commitments into the SaaS renewals, the crypto-agility investment targeted at the brittle self-built services the agility test flagged, and the dual-stack period during which the old PKI and the new one both run until the last dependent system moves.

Read what the exercise produced. Without spending a dollar figure, the build has already ranked the estate: the firmware fleet and the root-authority rebuild dominate, the modern services are the cheap part everyone over-focuses on, the vendor platforms are a timing and leverage problem rather than a labor problem, and three lines that no diagram shows are now on the page. That ranked, driver-by-driver structure is the defensible skeleton. Putting real numbers on each line, weighted to this specific estate, is the work that turns the skeleton into a figure a board can approve.

How do you frame and phase the final number?

A cost number sitting on its own doesn’t get funded, so the last move is to frame it against what it buys and to phase it across time. Frame the migration cost against what it protects, as a single investment figure a board can weigh the way it weighs any risk-reduction spend, which is the front door that the business case walks through.

Then price the cost of waiting honestly, without reaching for a scare number. The downside is specific and irreversible: every month the migration is late, more long-lived data is copied while it’s still under breakable cryptography, and no budget approved later can buy that data back. That is the harvest-now-decrypt-later loss, and it’s a cleaner argument than a fabricated breach figure because it’s simply true.

Phasing is the other half of framing, and it’s where starting early turns into money saved. Mosca’s theorem is the formal version: when the years your data must stay secret plus the years your migration takes exceed the years until a quantum computer arrives, you’re already behind, and behind is the expensive place to be.

An early start lets the spend spread across several budget cycles, keeps vendor leverage alive at each renewal, and does the same work calmly instead of paying overtime on a compressed sprint, while a late start forces the whole cost into one narrow window where it competes with everything else and can’t be smoothed. The receipt method is how you get an honest figure for how long your migration actually takes, by measuring your last completed crypto migration from decision to last-system-retired, so the phasing math uses your own history rather than a vendor’s forecast.

How do you use the cost build with a board?

The build is what lets you answer the one question a board always asks, which is “where did this number come from,” with a line-by-line answer instead of a shrug. Deploy it one level up like this:

1. Lead with the method, then the number. Say the figure was built by inventorying the estate and pricing each driver against what was found, the same way the federal government reached its published estimate. A board trusts a number whose provenance it can hear.
2. Show the drivers, ranked. Put the driver table in front of them so the largest and longest lines, legacy hardware and the certificate program, are visible as the real drivers rather than the algorithm swap everyone assumes is the cost.
3. Name the three forgotten lines out loud. Presenting procurement time, the agility project, and the dual-stack years before anyone asks is what signals the estimate is complete, because these are exactly the lines a sharp director probes for.
4. Ask for the inventory first, bounded by a ceiling. The most fundable request is a scoped, funded discovery phase with a not-to-exceed figure, because it produces the real total for every phase after it. That converts “we need an unknown amount for a multi-year effort” into “we need a bounded amount to find out exactly what this takes,” which is a yes a committee can give in the room. The full memo mechanics live in Brief Your Board.

The single most useful thing the cost build does in a boardroom is defend the number when it’s challenged, because a figure assembled from a counted estate answers the challenge with evidence while a rate-card figure answers it with a flinch.

Pro tips

1. Fund discovery as its own line, never as overhead folded into engineering. When discovery hides inside another budget line, it gets cut first under pressure, and cutting it removes the basis for every other number in the plan. Give it a named budget line so it survives.
2. Price the who-controls-it column before the how-many column. The fourth inventory question, who controls each surface, sets the vendor and hardware lines, which are the drivers that dominate the real bill. Estimators who price the systems they control first, because those are easy to count, build a number that looks complete and is missing its largest lines.
3. Ask the follow-up when a vendor quotes you a flat migration cost. The revealing question is “which of my systems did you inventory to produce that.” A quote that priced nothing specific in your estate is a list price, and the answer to the follow-up tells you which one you’re holding.
4. Put the dual-stack years on the operating budget, not the project budget. The overlap period is a running cost that outlives the migration project, so modeling it as a one-time project line understates it. It belongs where recurring costs live.
5. Re-price after discovery, on the record. The first estimate is built on a partial inventory by necessity, so it carries a stated uncertainty, exactly as the federal figure does. Re-issue the number once discovery matures and note that it moved, because a number that never changes as the inventory fills in is a number nobody updated.
6. Treat crypto-agility as the cheapest line in the budget, and say so. It’s the one line that lowers the cost of every future transition, so framing it as insurance that pays for itself is what keeps it from being the first thing cut.

Where does the inventory-first cost build break down?

The framework has honest limits, and naming them is part of using it well.

1. Estates mid-refresh, where the hardware driver is already funded elsewhere. The single biggest driver, legacy-hardware replacement, sometimes sits inside a capital refresh program that’s already budgeted and underway for reasons that have nothing to do with cryptography. When that’s true, adding the full hardware line to the migration budget double-counts it. The correct move is to record the hardware migration as riding on the existing refresh, price only the incremental cryptographic work it adds, and note the dependency, because the refresh schedule now sets that part of your timeline.
2. Very small or single-cloud estates. An organization with one cloud account and a handful of managed services can often size its migration on a single page, and the driver framework stops feeling like a framework. That’s success, not a failure. The drivers still name what to check, even when several of them come back as one line each.
3. Estates with no long-lived data. The framing move leans on data that must stay secret for years, and an estate whose data is all short-lived has a genuinely smaller and less urgent bill. The build still runs, but the harvest-now-decrypt-later argument is honestly weak, and the number should say so rather than borrow urgency it doesn’t have.
4. Before discovery has produced anything. The build cannot generate a defensible total on an un-inventoried estate, by design. Its first output on a cold start is the discovery ask, and anyone who wants a full number before that phase runs is asking for the guess the framework exists to refuse.

Common misconceptions

1. “There’s a standard per-system cost I can multiply out.” Cost scales with your legacy-hardware share, your vendor mix, and your compliance scope, so a per-system multiplier produces a tidy figure that can be wrong by an order of magnitude, because it prices the two drivers that usually dominate, hardware and vendor timelines, at whatever the rate card assumed. The defensible number comes from your inventory.
2. “The $7.1 billion federal figure tells me what I’ll pay.” That figure covers a decade across the entire federal civilian government and excludes national security systems, so it’s a sense of scale for a very large estate. Anchoring your budget to a national aggregate is how you land a number that sounds authoritative and can’t be defended.
3. “Discovery is a sunk cost I’d rather skip to save money.” Discovery is the pricing basis for every other line, so skipping it strands the rest of the estimate with nothing to price against, while the cost it was meant to measure stays exactly where it was. An estimate built without it is a guess in the shape of a budget.
4. “Benchmark shopping across vendors will give me the real range.” Collecting several vendors’ flat quotes averages several guesses, because none of them priced your estate. The range you get is the spread of their assumptions about a generic customer, which tells you about their pricing models rather than about your cost.
5. “We can defer the cost with no penalty.” Deferral is itself a cost. A deadline-compressed migration pays overtime on years of work crushed into a sprint, loses the vendor leverage you only have at renewal, and forfeits the ability to phase the spend across budget cycles, and the long-lived data harvested during the delay is gone for good.
6. “The algorithms cost money, so that’s the budget.” The algorithms are free NIST standards. The bill is the labor of finding and replacing cryptography across the estate, plus replacing legacy hardware that can’t be updated.

Questions people ask

How do I build a PQC migration budget when nobody will give me a number? Build it in one direction, which is count then price. Fund a cryptographic inventory first, price each cost driver against what it finds, add procurement time, the crypto-agility project, and the dual-stack period, then frame the total against what it protects. The inventory is what makes the number yours and defensible.

Why won’t any honest advisor just quote me a figure? Because the cost scales with your estate size, your legacy-hardware share, and how much of your estate a vendor controls, and none of that is known until discovery runs. Anyone who gives you a firm per-organization number before seeing your inventory is selling you a number rather than measuring your cost.

Can I use the federal $7.1 billion to estimate my share? No. It’s an aggregate of a decade of migration across the whole federal civilian government, it excludes national security systems, and it carries the government’s own high uncertainty, so it can’t be scaled down to one enterprise by any ratio. Use it as a sense of scale, and build your own number from your own inventory.

Source: Office of Management and Budget, “Report on Post-Quantum Cryptography,” July 2024, OMB PQC Report.

What’s usually the biggest cost driver? For most large organizations it’s legacy systems with cryptography embedded in hardware or firmware, which often can’t be updated and have to be replaced outright. The U.S. government’s report names exactly these systems as the most difficult and expensive to migrate.

Which line runs the longest? Usually the certificate and root-authority program, because rebuilding the trust hierarchy your whole estate depends on touches everything, has to happen in a safe order, and can’t be rushed. Length is a cost of its own, since a line that runs for years consumes governance, testing, and dual-running the entire time.

What are the three costs everyone forgets? Procurement cycle time, because vendor leverage exists at renewal; the parallel crypto-agility project, because it keeps the next transition from being another full program; and the dual-stack period, the years you run and pay for both cryptographies before you can turn the old one off.

How was the federal figure actually calculated? By count-then-price at national scale. OMB M-23-02 directed agencies to inventory their quantum-vulnerable systems and then submit a funding assessment 30 days later, and the $7.1 billion is the aggregate of those agency assessments. It’s the same two-step any organization runs, one estate instead of a whole government.

Source: Office of Management and Budget, “Migrating to Post-Quantum Cryptography,” Memorandum M-23-02, November 18, 2022, OMB M-23-02.

Does building crypto-agility make the migration cost more? It adds up-front cost and lowers the cost of every future transition, so it’s usually the cheapest insurance in the whole budget. Leaving it out makes this migration look cheaper and guarantees the next one costs the same as this one.

How do I keep vendor costs from ballooning? Put the requirement into the contract at procurement and renewal, when your leverage is highest. A vendor timeline negotiated early costs far less than one you’re chasing against a deadline, because a late buyer has no room to compress a supplier’s schedule.

---

Everything here is the map, given freely. When your team needs its estate inventoried, each cost driver weighted against its own legacy-hardware and vendor mix, and a phased budget a finance committee will actually approve, that’s the work I do. Request the workshop.

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