The program office has two categories of spending: IT infrastructure and warfighter capability. Infrastructure keeps the system running. Capability makes it better. Both come from the same budget.
Every dollar spent maintaining dedicated IT infrastructure for processing that could run on an enterprise platform is a dollar that doesn't fund a better algorithm, a faster processing pipeline, integration with a new sensor, or a modernized operator interface. The program office isn't choosing between "our infrastructure" and "their infrastructure." It's choosing between maintaining IT and investing in mission.
Why waves
No program office should be asked to move a high-availability weapon system to enterprise infrastructure in a single step. The risk is unnecessary and the resistance is justified.
A wave migration does three things:
-
Delivers savings before the next wave begins. Each wave reduces infrastructure cost. The savings from Wave 1 help justify Wave 2. The program office sees results before committing further.
-
Builds confidence empirically. Each wave proves — through operation, not briefings — that the enterprise platform meets the weapon system's requirements for that class of workload. The program office learns what works before moving anything more critical.
-
Preserves what genuinely needs to stay. The dedicated hardware that has real technical requirements for isolation remains dedicated. The wave migration identifies what that is — empirically — rather than assuming everything requires it.
The waves
Wave 1 — Non-real-time processing
Analytics, historical data queries, reporting, and training environments move first. These workloads:
- Have no availability requirement that enterprise infrastructure can't meet
- Consume compute, storage, and staff at every site they run on
- Are the lowest-risk workloads to migrate because their failure doesn't affect the operational mission
- Often run on the oldest, most maintenance-intensive hardware because they're the lowest priority for refresh
What the program gains: Immediate reduction in hardware, storage, and staffing costs at every site where these workloads currently run. Training environments — which often duplicate production infrastructure at significant cost — move to a platform where provisioning a new environment is an API call, not a procurement.
Wave 2 — Development and test environments
If the weapon system's dev/test environment runs on dedicated hardware at a dedicated site, that hardware is duplicating what the enterprise platform already provides. Moving dev/test to enterprise:
- Gives developers access to the same DevSecOps pipeline the platform provides — automated builds, automated security scans, automated deployment
- Reduces the time between a code change and a tested, deployable artifact
- Eliminates the hardware refresh and maintenance cost of a dedicated dev/test environment
- Aligns the development environment with the production target — which means fewer surprises at deployment
What the program gains: Faster software delivery, lower dev/test infrastructure cost, and a development pipeline that produces tested, hardened artifacts ready for deployment. This is where DevSecOps delivers the most visible improvement to the program office — the cycle time from requirement to fielded capability shortens measurably.
Wave 3 — Operational processing
For weapon systems where operator consoles and central processing have already migrated to software on standard servers — a pattern that industry trends and hardware refresh cycles have made increasingly common — these workloads are already software running on dedicated infrastructure. They are candidates for enterprise.
This is the wave the program office is cautious about, and that caution is appropriate. These workloads move when the enterprise platform has demonstrated — through Waves 1 and 2, and through explicit performance and availability testing — that it meets the weapon system's specific operational requirements.
Each weapon system needs its own assessment for this wave. The authorization pathway for migrating operational processing from dedicated infrastructure to an enterprise platform spans security boundaries — the weapon system's existing authorization, the enterprise platform's authorization, and the interconnect between them. The data flows, the classification levels, and the availability thresholds are specific to each system.
What the program gains: The largest infrastructure cost reduction. Operational processing at distributed sites is the most expensive workload to maintain on dedicated hardware — it drives the hardware refresh cycle, the security staffing, the standalone ATO, and the dedicated patching. Moving it to enterprise consolidates all of those costs into the platform fee. And the authorization shifts from a standalone system-level ATO to an application-level assessment on the enterprise platform — a narrower, faster review that frees SCA capacity in the AO's office for the systems that still require standalone authorization.
What stays dedicated
Sensor hardware, real-time signal processing at the edge, specialized communications equipment, and any processing with a genuine technical requirement for dedicated infrastructure. The purpose of the wave migration isn't to eliminate dedicated hardware — it's to ensure that dedicated hardware exists because of a validated technical requirement, not because the architecture predates the enterprise alternative.
The data volume between sensor hardware and enterprise processing is typically modest, but the link must be highly reliable. The interconnect between the dedicated hardware boundary and the enterprise platform is a design problem — and it's a solvable one. The architecture defines what data crosses that boundary, at what classification, with what reliability requirement, and the interconnect agreement governs how it's secured.
The math
For a weapon system spending $10-15 million annually on dedicated IT infrastructure across multiple sites:
| Wave | IT Cost Reduction | Timeline |
|---|---|---|
| Wave 1 — Non-real-time | 15-25% ($1.5-3.5M/year) | 6-12 months |
| Wave 2 — Dev/test | 10-15% ($1-2M/year) | 6-12 months |
| Wave 3 — Operational | 30-40% ($3-6M/year) | 12-24 months |
| Total | 55-80% ($6-11M/year) | 24-48 months |
The remaining 20-45% covers the dedicated hardware that stays, the platform fees for enterprise services, and the application-level sustainment that the program still owns.
Over a 10-year remaining lifecycle, the cumulative savings are $60-110 million — per system. For a portfolio of 10 similar weapon systems, the savings are measured in hundreds of millions, potentially exceeding a billion dollars over the portfolio lifecycle.
These are modeled estimates based on the infrastructure cost components described in the first post. The actual numbers depend on the specific weapon system — its site distribution, its hardware age, its staffing model, and its contractual structure. Each system needs its own assessment.
Where the money goes
The savings from infrastructure consolidation don't disappear into the enterprise platform budget. They remain in the program office's control — available for the capability investments the warfighter actually needs:
- Better algorithms. The processing that runs on the enterprise platform can be updated faster, because the DevSecOps pipeline reduces the deployment cycle from months to days.
- New sensor integration. The architecture that separates the sensor edge from the enterprise processing makes it easier to integrate new data sources without rebuilding the infrastructure.
- Modernized interfaces. Operator consoles that run as applications on an enterprise platform can be updated independently of the infrastructure — new interfaces, new visualizations, new workflows.
- Faster delivery. The DevSecOps pipeline, the shared testing infrastructure, and the application-level authorization (instead of system-level ATO) all reduce the time between a capability decision and a fielded improvement.
- Faster authorization. Application-level assessments on the enterprise platform are narrower and faster than standalone system ATOs. And every system that moves off a standalone authorization frees SCA capacity in the AO's office — which means the remaining assessments across the entire portfolio move faster, not just yours.
IT infrastructure is a support cost. It's necessary, but it doesn't make the weapon system more capable. Every dollar the program office converts from infrastructure maintenance to capability development is a dollar that directly benefits the warfighter.
This is already happening
The Space Force is executing this migration pattern now. The FORGE program is moving SBIRS missile warning ground processing from dedicated infrastructure to the Enterprise Ground Services architecture — a common platform designed to host multiple satellite ground systems. The SATCOM portfolio consolidated four independent ground systems (AEHF, Milstar, WGS, DSCS) under a single sustainment contract. The ISC2 modernization is integrating 40 stovepiped C2 systems. The Army runs GCCS on enterprise networks.
Each of these is a wave migration — workloads moving from dedicated infrastructure to shared platforms in phases, with the dedicated hardware that genuinely requires isolation remaining in place. The trajectory across the Department is clear: enterprise where the platform meets the requirement, dedicated only where there's a validated technical reason.
The question for a program office managing weapon systems on dedicated infrastructure isn't whether this transition is happening. It's whether to lead it — and capture the budget savings — or wait until the mandate arrives.
Getting started
The assessment path for a weapon system IT modernization has two layers:
Portfolio architecture assessment. For a program office managing multiple weapon systems on dedicated infrastructure, the first question is: what does the target architecture look like? Which enterprise platform serves as the consolidation target? What are the common workload patterns across systems? What is the migration sequence? This is an architecture study that scopes the overall approach before any individual system moves.
Per-system authorization study. Each weapon system that migrates needs its own assessment — mapping the current architecture, evaluating which workloads can move to enterprise, identifying the authorization pathway for the migration, scoping the interconnect between dedicated and enterprise boundaries, and producing a costed migration plan. This is a systems authorization study specific to the weapon system.
The portfolio assessment tells the program office what the overall migration looks like and what the aggregate savings are. The per-system studies tell it exactly what each migration requires, costs, and delivers. Both are prerequisites for an informed decision — and both are cheaper than one year of maintaining the infrastructure they're evaluating.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has served as ISSM and ISSE for legacy weapon systems at the Air Force Lifecycle Management Center — operating the dedicated IT environments this series describes — and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO).
If your program manages weapon systems on dedicated IT infrastructure and wants to understand what a migration path looks like — starting with the cost visibility and architecture assessment — contact Millabs. These assessments can be performed independently on behalf of the program office through existing government contract vehicles.