The U.S. Army’s incremental modernization of tactical infrastructure is a pragmatic blueprint for how to move a highly constrained, legacy-dependent operational estate toward a cloud- and container-friendly future without breaking current capability or the budget that sustains it.
Background / Overview
Modern warfare and modern software development have both accelerated faster than many defense acquisition cycles. Tactical infrastructure fielded a decade ago was designed for a different operational and technical baseline:
bare-metal appliances, monolithic software stacks, and virtualization models optimized for on‑prem data centers — not for distributed, intermittently connected, Size‑Weight‑and‑Power (SWaP)-constrained environments. The U.S. Army Communications‑Electronics Command Software Engineering Center (CECOM SEC) has taken on the tightrope task of preserving current warfighting capabilities while creating a platform that supports modern development practices like containers, automation, and cloud‑style operations.
The Army’s modernization program is driven by three overlapping pressures:
- The need for agility — faster fielding cycles, automated deployments, and reduced technical debt.
- The reality of tactical constraints — air‑gapped or severely degraded networks, ruggedized hardware that cannot be frequently replaced, and operators under combat and peacetime workload stresses.
- The cost of legacy vendor licensing and total cost of ownership concerns that make alternatives attractive.
CECOM SEC’s approach is deliberately incremental. Rather than force a wholesale rewrite of legacy applications, their work focuses on building an operationally realistic path for migration: in‑place hypervisor upgrades (VMware → Microsoft Hyper‑V), modular hardware baselines that can host cloud-like services at the brigade level, and a container‑native replatforming for key systems like Distributed Common Ground System‑Army (DCGS‑A). In between these milestones are the important bridging pieces — packaging and air‑gap tooling, VM lifecycle management inside Kubernetes, and operator‑centric automation — that make modernization usable in the field.
Why the tactical problem is not the same as enterprise cloud migration
Modern enterprise cloud migration strategies often assume near‑constant connectivity, ample bandwidth, power and cooling, and the ability to centralize telemetry and patching through the public internet. None of these assumptions hold consistently at the tactical edge.
- Tactical systems must operate under Denied, Degraded, Intermittent, and Limited (DDIL) networks. This means deployment models and toolchains must support fully disconnected installs and updates.
- Hardware at the edge is constrained by SWaP; choosing heavy compute footprints is not feasible on many platforms.
- Operator burden is real: Soldiers and tactical IT personnel are trained for mission tasks first — asking them to become Kubernetes cluster administrators in austere conditions is unrealistic.
- Many Army applications were written for bare‑metal or VM hosts and assume local filesystem semantics or the presence of specialized peripherals. Rewriting them for cloud-native patterns can require substantial funding and time that acquisition pipelines do not always provide.
The result is a dual‑track requirement: keep legacy workloads running securely while creating a stable, repeatable path for containerized and cloud‑capable workloads that can run in DDIL contexts.
What CECOM SEC is doing: a practical catalogue of initiatives
CECOM SEC’s modernization portfolio can be grouped into three practical lines of effort. Each is designed to reduce dependence on a single commercial vendor, lower operating cost, or enable cloud‑native practices in ways that respect tactical realities.
1) TSI v5 / v1 — in‑place migration from VMware to Microsoft Hyper‑V
CECOM SEC identified that existing
Tactical Services Infrastructure (TSI) v5/v1 stacks relied on VMware for virtualization but faced two problems: funding constraints and sharp changes in vendor licensing economics that materially raised total cost of ownership for small tactical footprints.
Their engineering decision: perform a
non‑destructive, in‑place migration from VMware to
Microsoft Hyper‑V, preserving unit configurations and mission data rather than forcing a time‑consuming rebuild. The rationale is straightforward:
- Many operators already know Windows Server administration, and Hyper‑V licensing frequently exists within enterprise license agreements, which reduces new license acquisition complexity.
- An in‑place migration minimizes downtime and preserves battlefield readiness during the transition.
CECOM SEC also provisioned this Hyper‑V baseline with a lightweight container layer for future workloads — initially using
Docker Swarm surfaced through
Portainer to give operators a simpler, opinionated container controller that is easier to operate in constrained environments than a full Kubernetes distribution. That choice reflects the operational tradeoff: minimize training burden while enabling container packaging and lifecycle management.
Key benefits:
- Preserves current investments and unit data.
- Reduces near‑term license shock and administrative churn.
- Provides a clear migration path to containers without forcing immediate, risky refactors.
Caveat: this is an incremental step, not a final state. Docker Swarm and Portainer are pragmatic stopgaps that trade some orchestration features for
operational simplicity — appropriate for many tactical users, but limited compared to full Kubernetes ecosystems when it comes to advanced scheduling, service meshes, and ecosystem integrations.
2) Cloud‑Enabled Modular Infrastructure (CEMI) for TSI v2 / v3
For the older hardware baselines (TSI v2/v3), CECOM partnered with Program Executive Offices to design a
cloud‑enabled, modular physical baseline — sometimes called CEMI in documentation — intended to bring containerization and cloud‑like management down to brigade echelons.
Core design goals:
- Modularity: discrete compute, storage, and network modules that can be combined for mission needs.
- Scalability: quick add/remove capability for modules to adapt to changing mission loads without system overhauls.
- Cloud integration: optional management via cloud control planes where connectivity exists, plus local control when disconnected.
- Rapid deployment: pre‑validated modules and container images for field install.
- Cost discipline: assess open‑source and low‑cost OS options to minimize license overhead.
CECOM SEC emphasized Soldier touchpoints and demos during development to ensure the user interface automation and management capabilities match warfighter expectations.
Risk and reality check:
- Modular hardware reduces refresh pain but still requires logistics for spares and lifecycle management.
- Cloud integration raises questions about sovereignty, telemetry, and how to stage updates into DDIL environments safely.
3) DCGS‑A — container‑native replatforming with Red Hat OpenShift
For high‑value, high‑tempo systems like
DCGS‑A, CECOM SEC pursued a container‑native architecture based on
Red Hat OpenShift. The benefits here are substantial:
- OpenShift provides an enterprise Kubernetes distribution with lifecycle management, integrated CI/CD hooks, and enterprise support for stateful workloads.
- Containerization reduces technical debt by making automated deployments, security scanning, and image‑based rolling updates possible.
- For intelligence systems, automated and auditable delivery pipelines improve repeatability under operational pressure.
This is a strategic pivot: moving a large, intelligence‑centric software suite to a platform that supports automated scaling, image inventory, and DevSecOps pipelines.
Operational caveats:
- OpenShift itself is not a silver bullet; it requires infrastructure, training, and change‑control discipline.
- Containerizing stateful intelligence workloads requires additional investments in persistent storage, backup/restore practices, and data sovereignty controls.
Technical enablers and bridging technologies
CECOM SEC’s approach is not an all‑or‑nothing rip and replace. Instead, several
bridging technologies make co‑existence and incremental migration possible.
KubeVirt — running legacy VMs inside Kubernetes
One of the most powerful bridging techniques is
hosting legacy VMs inside containers using
KubeVirt. KubeVirt extends Kubernetes with VirtualMachine CRDs, permitting the orchestration of full virtual machines alongside pods. That enables:
- Gradual migration: legacy VMs can be scheduled and managed with a single control plane.
- Unified operations: backup, monitoring, and RBAC can be consolidated under Kubernetes tooling.
- Live migration support, snapshots, and VM lifecycle integration with container orchestration pipelines.
KubeVirt is an industry‑mature project with established deployment patterns; in a tactical context, it lets teams avoid risky, immediate rewrites while making VM workloads visible to modern SRE/DevSecOps tools.
Air‑gap packaging and delivery: Zarf and Hauler
Disconnected and air‑gapped installations are a fundamental tactical reality. Two projects are notable:
- Zarf — an open‑source DevSecOps packaging tool originally developed by Defense Unicorns. Zarf’s model packages all required application artifacts (images, manifests, SBOMs, scripts) into a single distributable artifact that can be transferred to disconnected clusters and installed deterministically. Its design focuses on zero dependencies, reproducibility, and supply chain integrity.
- Hauler — a lightweight, government‑oriented artifact management binary from Rancher designed specifically for air‑gapped workflows. Hauler pulls, stores, and bundles container images, Helm charts, and supporting artifacts into archives that can be loaded into isolated registries and clusters. It’s positioned as a practical, small‑footprint solution for artifact transfer and private registries.
Together, Zarf and Hauler represent the practical workarounds that let continuous delivery patterns exist even when the production environment is physically disconnected. They solve the logistical problem of "how do I move the internet to a tent in the desert" without requiring operators to become packaging experts.
Lightweight container controllers: Docker Swarm + Portainer
Where Kubernetes is too heavy or training resources are scarce,
Docker Swarm + Portainer can provide an operationally simpler experience:
- Docker Swarm offers a lightweight orchestrator with a smaller operational surface.
- Portainer adds a GUI and simplified management that is easier to teach and operate under stress.
This combination is purposefully conservative: not every tactical site will need the full power of Kubernetes, and the initial goal is to reduce operator burden while enabling container packaging and lifecycle control.
Strategic analysis — strengths, tradeoffs, and operational risks
CECOM SEC’s work is notable for pragmatism: rather than demanding instant modernization, it builds a migration path that respects funding realities, operator skillsets, and the unique constraints of tactical environments. But practicality carries tradeoffs and risks that require honest appraisal.
Strengths and what the Army gets right
- Incrementalism reduces operational risk. Non‑destructive in‑place migrations preserve mission capability and simplify certification and acceptance testing.
- Operator-centered design. Soldier touchpoints and UI automation prioritize adoption, which is essential for long‑term sustainment.
- Bridging technologies protect investments. KubeVirt and air‑gap packaging tools reduce the immediate need for costly rewrites.
- Vendor diversification. Moving away from single-vendor dependency for hypervisors and embracing open toolchains reduces strategic supplier risk and TCO exposure.
- DevSecOps and containers for DCGS‑A. Containerization for intelligence systems brings faster, more repeatable updates and security scanning opportunities.
Tradeoffs and technical debt risks
- Operational overhead of multiple platforms. Maintaining both Hyper‑V and Kubernetes/Swarm footprints increases the variety of tooling and support processes teams must know.
- Containerization is not free. Rewriting or refactoring legacy applications is expensive. KubeVirt is a strong stopgap, but it can add complexity when mixing VM and container networking and storage semantics.
- Air‑gap logistics remain a programmatic challenge. Zarf and Hauler simplify packaging but still require disciplined repository management, secure transfer workflows, and chain‑of‑custody controls.
- Training and human factors. Even with simplified UIs, the shift to image‑based delivery, SBOM, and container security scanning requires changes to daily ops and troubleshooting workflows.
Security and supply chain concerns
- Image provenance and SBOM discipline. Containers and packaged artifacts must carry verifiable Software Bill of Materials and signed images to avoid supply‑chain compromises.
- Patch delivery in DDIL. For air‑gapped stacks, delivering urgent firmware and security patches requires secure, traceable offline update mechanisms and tested rollback procedures.
- Policy maturity for containers. The Army needs hardened base images, scanning policies, and governance for container runtime security — a community DevSecOps project is already tackling these, but institutionalized policy is essential.
Vendor licensing and procurement dynamics (a practical constraint)
A major practical driver cited for the TSI Hyper‑V migration is vendor licensing economics. Industry reporting and program discussions indicate that post‑acquisition licensing changes by commercial hypervisor vendors materially increased the cost profile for small tactical deployments. This drove a pragmatic decision to leverage Hyper‑V where existing enterprise license agreements and operator familiarity reduced procurement complexity.
A note of caution: public reporting on specific licensing thresholds and minimums has been fluid. Some vendor minimums and purchase rules announced in the marketplace were later adjusted or clarified. Program teams should always demand written, contract‑level confirmation of license entitlements and pricing and model costs across realistic hardware life cycles before switching platforms.
Practical recommendations for program managers and operators
CECOM SEC’s work offers replicable lessons for any organization modernizing constrained, mission‑critical infrastructure. Program leads and system integrators should consider the following concrete steps.
- Inventory and classify:
- Catalog applications by deployment model (bare‑metal, VM, container) and map to business value and migration complexity.
- Choose migration patterns deliberately:
- Use in‑place hypervisor migrations to eliminate licensing surprises where possible.
- Use KubeVirt to host stubborn legacy VMs while building container pipelines for new features.
- Build air‑gap playbooks:
- Standardize packaging with Zarf/Hauler and define chain‑of‑custody, SBOM and signature verification procedures.
- Prioritize operator UX:
- Invest in simple, GUI‑driven workflows for common tasks (deploy, patch, rollback) and preserve manual options for troubleshooting.
- Harden from the start:
- Adopt hardened base images, automated scanning, and automated RBAC and secrets management for containerized workloads.
- Model total cost of ownership:
- Include license trajectories, training, personnel churn, and logistics in any procurement decision.
- Pilot, measure, iterate:
- Run defined pilots at multiple echelons and collect operational metrics (time to deploy, patch latency, operator errors) to inform wider rollouts.
Lessons learned and the cultural dimension
Modernization is as much organizational as it is technical. The Army’s experience emphasizes a few essential cultural lessons:
- Co‑design with operators is non‑negotiable. Soldier touchpoints drive adoption and reveal hidden operational constraints that laboratory tests miss.
- Automation must be explainable. Operators must understand the automation sufficiently to trust and troubleshoot it; “black‑box” automation will be resisted.
- Balance control and empowerment. Skilled IT teams want fine‑grained manual controls; less skilled operators need one‑click simplicity. Systems must provide both.
- Policy follows practice. Technical proofs of concept should be paired with policy work that codifies container base images, scanning requirements, and governance models so deployments can scale securely.
Looking ahead — what modernization enables and what remains to be solved
CECOM SEC’s incremental modernization anchors several strategic capabilities for the Army:
- Faster, more auditable software delivery for intelligence and command systems.
- Reduced lock‑in risk through open toolchains and diversified hypervisor choices.
- Field‑feasible container operations enabled by air‑gap packaging and simplified orchestration.
However, critical pieces still demand investment:
- Comprehensive training pipelines to build SRE/DevSecOps competency in the force.
- Sustained funding for containerization efforts — refactoring legacy software remains expensive and requires multi‑year commitments.
- Enterprise policies for container security and SBOM enforcement to make container adoption safe at scale.
- Robust, auditable offline update mechanisms for firmware and OS images to close the patching gap in disconnected environments.
Conclusion
The Army’s approach — pragmatic, incremental, and operator‑focused — is an instructive model for any organization faced with modernizing constrained, mission‑critical infrastructure. By pairing in‑place hypervisor migrations with pragmatic container and packaging bridges, CECOM SEC reduces immediate risk while steadily maturing capabilities that support DevSecOps, reproducible deployments, and cloud‑like operations at the tactical edge.
The central lesson is clear: modernization that ignores operator burden and tactical realities will fail. The Army’s path shows that with careful tool selection (KubeVirt for VMs, Zarf/Hauler for air‑gap delivery, conservative orchestration like Docker Swarm where appropriate), disciplined policy work, and continual soldier engagement, it is possible to preserve readiness today while enabling a sustainable, more agile infrastructure tomorrow.
Operational modernization is not a single project — it is the continuous practice of engineering systems that respect constraints, reduce operator friction, and steadily de‑risk the transition from legacy to cloud‑native operations.
Source: army.mil
Modernizing tactical infrastructure