The most common reason a program office gives for maintaining dedicated IT infrastructure is availability. The weapon system is high-availability. It processes sensor data, supports command decisions, or contributes to national defense functions that cannot tolerate downtime. The program office has maintained its own infrastructure for years and it meets the requirement. Why would they risk moving to a shared platform?
This concern is legitimate. It should be taken seriously. And it should also be tested against the evidence, because the assumption that dedicated infrastructure is inherently more reliable than enterprise infrastructure doesn't hold up when you look at systems that have already made the transition.
The reliability assumption
Program offices managing high-availability weapon systems often operate from a mental model where dedicated equals reliable. The reasoning is intuitive: if the infrastructure is dedicated to one mission, nothing else can disrupt it. No other tenant can consume resources. No platform change can introduce an unexpected dependency. The program controls everything.
In practice, "the program controls everything" means the program is responsible for everything — including the infrastructure expertise required to maintain high availability. That means:
- Redundancy design is scoped and funded by the weapon system program, not by an infrastructure organization whose core competency is redundancy
- Failure response depends on staff who primarily understand the weapon system, not staff who primarily understand infrastructure
- Capacity planning is managed by a program office that sees infrastructure as overhead, not by an operations team that sees it as their mission
- Patching cadence is driven by the weapon system's schedule and risk tolerance, which often means patches are deferred — and deferred patches become security findings that compound over time
A dedicated infrastructure isn't automatically more reliable. It's more familiar. Familiarity is not the same as superiority, and it comes at the cost of maintaining infrastructure expertise that enterprise platforms provide as a core capability.
Systems that already run on enterprise infrastructure
The Army's Global Command and Control System (GCCS) runs on DISN enterprise networks. GCCS is a high-availability command and control system supporting operational decisions across combatant commands. It meets its availability requirements on shared infrastructure — not because the infrastructure is less rigorous, but because the enterprise network is operated by an organization whose entire mission is maintaining that infrastructure.
Platform One and its Big Bang-derived variants host dozens of mission applications across the Department. These platforms provide hardened Kubernetes substrates with service mesh, policy enforcement, continuous monitoring, and automated patching — operated by dedicated platform teams with deeper infrastructure expertise than any single weapon system program office can maintain independently.
The ISC2 modernization is integrating approximately 40 stovepiped systems under an open, standards-based architecture — including systems that were previously considered too critical for shared infrastructure. The architecture supports real-time data sharing across joint systems, sensors, and services.
Space ground systems — where availability requirements are as high as they get — are making the same move. The Space Force's FORGE program is transitioning SBIRS missile warning ground processing from a dedicated, single-prime infrastructure to the Enterprise Ground Services (EGS) architecture — a common services platform designed to host multiple satellite ground systems on shared infrastructure. The SATCOM portfolio has already consolidated: AEHF, Milstar, WGS, and DSCS ground systems — four independent stovepipes doing fundamentally similar command-and-control work — are now managed under a single sustainment contract. If missile warning and satellite communications can meet their availability requirements on shared enterprise architecture, the reliability argument for dedicated infrastructure in other weapon systems deserves scrutiny.
These aren't experiments or pilots. They're operational systems — including some of the most availability-critical systems in the Department — that made or are making the transition. In many cases, reliability improves because the enterprise platform provides redundancy, monitoring, and rapid failover capabilities that individual weapon system programs couldn't afford to build independently.
What enterprise platforms actually provide
The concern about "shared infrastructure" often assumes a model where weapon systems compete for resources on a best-effort basis. Modern enterprise platforms for DoW environments don't work that way:
Resource isolation. Kubernetes namespaces, resource quotas, and network policies provide tenant isolation at the platform level. One application's resource consumption doesn't affect another's. The infrastructure is shared; the resource allocation is dedicated.
Redundancy by design. Enterprise platforms are built for high availability — multi-zone deployments, automated failover, health monitoring, and self-healing. A single weapon system program office maintaining its own redundancy at multiple sites is replicating — at program expense — what the enterprise platform provides as a baseline capability.
Faster patching. Enterprise platforms patch once and deploy to all tenants. A weapon system on dedicated infrastructure patches once and deploys to itself — at the same cost per patch but with none of the scale benefit. And because patching on dedicated infrastructure is a standalone risk decision for each system, patches are more likely to be deferred — which means the dedicated system is often running older, less secure software than the enterprise platform.
Deeper operational expertise. The team operating the enterprise platform does infrastructure as their primary mission. The team operating a weapon system's dedicated infrastructure does infrastructure as a secondary responsibility alongside the weapon system mission. When infrastructure fails, which team responds faster and more effectively?
Shared authorization. The enterprise platform carries the infrastructure ATO. Weapon systems deploying on the platform authorize at the application level — a faster, narrower assessment scoped to what the weapon system actually changes, not the full infrastructure stack. This matters beyond the program office: the Authorizing Official's organization has finite capacity. Every standalone weapon system ATO requires its own Security Control Assessment from a shared pool of SCAs. Program offices waiting months for an available assessor is a common experience — and every system that moves to the enterprise platform is one fewer standalone authorization competing for that capacity. The AO's office gets bandwidth back, assessments move faster across the portfolio, and the program office's own authorization timeline shortens.
What genuinely requires dedicated infrastructure
Not everything can or should move to an enterprise platform. Some processing has real technical requirements for dedicated hardware:
- Sensor interfaces that require direct hardware access, specialized I/O, or real-time processing below the latency threshold of a virtualized environment
- Edge processing at remote or forward-deployed sites where enterprise platform connectivity isn't available or reliable
- Specialized communications equipment with hardware security requirements that can't be met by a shared platform
- Processing with classification constraints that exceed what the enterprise platform is authorized to handle
These are genuine technical requirements — and they're testable. The question for each workload isn't "is this critical?" (they're all critical) but "does this workload have a specific technical requirement that the enterprise platform can't meet?" If the answer is yes, it stays on dedicated hardware. If the answer is "we've always done it this way," that's an assumption worth testing.
How to test the assumption
The program office doesn't need to trust that the enterprise platform meets its availability requirements. It needs to verify it.
This is an empirical question, and it has an empirical answer. Deploy the weapon system's software against the enterprise platform in a test environment. Measure latency, throughput, failover time, and resource utilization under realistic load. Compare those measurements against the weapon system's published availability and performance requirements.
If the enterprise platform meets the requirements, the reliability argument for dedicated infrastructure doesn't apply to that workload. If it doesn't meet the requirements, the test identifies specifically what falls short — and the program office makes an informed decision about which workloads can migrate and which genuinely need dedicated hardware.
Each weapon system needs its own evaluation. The architecture, the performance requirements, the data flows, and the availability thresholds are different for each system. A sensor processing system with sub-millisecond latency requirements has different constraints than a command and control platform processing operational messages. The evaluation is per-system — and the result is specific, not generic.
The cost of not testing
A program office that assumes its weapon system requires dedicated infrastructure — without testing that assumption against an enterprise alternative — is committing to the infrastructure cost described in the previous post for the remaining lifecycle of the system. For a system with 15-20 years of remaining service, that's a decision worth $150-300 million in infrastructure spending that may not be necessary.
The test costs a fraction of one year's infrastructure budget. The answer it produces — empirical, specific, defensible — is worth the entire remaining lifecycle.
Next in this series: how a phased migration frees budget for warfighter capability.
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, maintaining authorizations for high-availability systems on dedicated infrastructure, and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO).
If your program assumes its weapon system requires dedicated infrastructure and that assumption hasn't been tested, contact Millabs. The assessment is per-system, empirical, and can be performed independently on behalf of the program office through existing government contract vehicles.