Right now, in a great many program offices, the modernization conversation is a virtualization licensing conversation. The renewal quote arrived, it was a multiple of the last one, and it has done what years of architecture briefings could not: it got leadership's attention.
Use the attention. Just do not build the business case on it, because it will not hold.
Where the money actually is
In a cleared, air-gapped estate, the dominant cost is cleared labor. Infrastructure operations, the authorization program, and manual cross-domain transfer, performed by people who hold clearances and work on site.
Software licensing is real money and it is not in the same weight class. Neither is hardware amortization. When you decompose an estate like this honestly, the labor lines and the license lines are not comparable quantities, and the hypervisor is a portion of the license lines.
Which produces an uncomfortable result: you can win the licensing argument completely, replace the stack, absorb the migration, and the estate will cost close to what it cost before.
Run the test yourself
Here is a one-question version, and it is worth actually doing before anyone writes a decision memo.
If the virtualization licensing line went to zero tomorrow, would this estate be meaningfully cheaper?
If the answer is no, then licensing is not your business case, and pitching it as one has a predictable failure mode. You will be asked for the payback period. The payback period on a platform migration in an air-gapped classified environment, where every step is performed by cleared staff on site and every change goes through assessment, is long. Long enough that a comptroller will decline, and long enough that declining is the right call on the numbers as presented.
Then you have spent your one moment of leadership attention on the argument that could not carry the weight.
Two reasons to do it anyway
None of this says keep the stack. There are two good arguments, and neither is payback.
The escalation curve. The issue with a licensing line that repriced sharply once is not this year's number, it is that you no longer control next year's. A cost you cannot forecast is a planning problem regardless of its size, and reducing exposure to it is a legitimate objective on its own terms.
Coupling. The deeper cost of a proprietary virtualization and desktop-brokering stack in a classified estate is that it shapes your operating model. Image build, provisioning, patching and the desktop delivery model are all defined by the vendor's tooling. As long as they are, the parts of your estate that could be defined as code, assessed once and reused across domains cannot be, because they are expressed in a stack that does not work that way. Decoupling is a precondition for the thing in post seven that actually moves cost.
That second argument is the real one, and it is stronger than the first because it connects to the structural fix rather than sitting beside it.
How to sequence it
Do the virtualization work as phase one of a modernization, not as the modernization. It is a reasonable place to start: the pressure is real, the attention exists, the scope is contained, and it removes a constraint on everything after it.
Say clearly what it is and is not. It reduces an escalating and unpredictable cost, and it decouples the operating model. It does not, by itself, change what you inherit, how many boundaries you authorize, or how much work sits on the high side, and those are the things that set the bill.
A proposal that claims a hypervisor migration pays for itself will be checked, and it will not survive the check. A proposal that says this removes an unforecastable cost and unblocks the changes that do pay is both true and harder to argue with.
Robert Burckner is the founder of Millabs Corporation. He has served as ISSM and ISSE for legacy weapon systems and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO).