Avoiding Vendor Lock-In in AI Procurement

Vendor lock-in occurs when switching costs become prohibitively high (Greenstein 1997; Opara‑Martins et al. 2016), creating dependencies that limit competition and innovation. As Max Weber presciently observed, what begins as a useful tool can become an “iron cage” of constraint (Weber 1930). In military AI procurement, this risk is particularly acute (U.S. Government Accountability Office, 2023). The 2021 United States Department of Agriculture (USDA) case study illustrates the magnitude: the Department paid $112 million more for Microsoft Office than Google Workspace, specifically to avoid even higher switching costs (U.S. Government Accountability Office 2021).

The Department of War has elevated vendor lock-in avoidance from aspirational best practice to mandatory acquisition policy. In his November 7, 2025, speech at the National War College outlining major defense acquisition reforms, Secretary Pete Hegseth established “supply chain resilience” as one of four core structural requirements for defense contractors (Hegseth 2025; Katz 2025). This requirement explicitly mandates that contractors “maintain at least two qualified sources for critical program content” specifically to “prevent vendor lock-in situations” (Serbu 2025). This policy directive positions vendor independence as a fundamental principle of DoW acquisition strategy, alongside speed to delivery, commercial technology adoption, and performance-based contracting (Gordon 2025). For AI and machine learning systems increasingly critical to naval combat decisions, sensor fusion, and autonomous operations, this mandate creates both opportunity and urgency for implementing platform-independent architectures.

This paper provides concrete, actionable recommendations for avoiding vendor lock-in in DoW AI procurement through three complementary approaches: technical strategies for platform independence, strategic procurement and contracting reforms, and organizational implementation roadmaps. We demonstrate that vendor independence is both technically feasible and operationally essential for maintaining technological superiority.

This paper predominantly uses U.S. Department of War (DoW) terminology because the policy artifacts that anchor it — the Hegseth acquisition reforms, FAR/FASCSA, GIDE, and so on — are U.S. Equivalent constructs exist in other allied defence establishments (the U.K., Australia, Canada, the E.U., and NATO partners) and in regulated civilian sectors (health, finance, energy, critical infrastructure) that face the same lock-in mechanics: large, slow procurement cycles, classification or compliance restrictions, and proprietary platform stacks. The technical patterns, such as containerization, Open Neural Network Exchange (ONNX), and Infrastructure-as-Code, and procurement patterns, such as modular contracting, dual-source requirements, and performance-based contracts, generalize well with the labels swapped. Where a DoW-specific term first appears, we expand the acronym and, where useful, note the generic concept it instantiates so readers in other ministries, agencies, or industries can map the discussion onto their own equivalents.

In machine learning (ML) platforms, vendor lock-in manifests primarily through proprietary application programming interfaces (API), custom data formats, specialized training environments, and integrated toolchains that resist migration. The DoW faces unique challenges: classified data restrictions, security requirements, and mission-critical uptime that amplify switching costs beyond typical commercial scenarios. Where AI systems increasingly drive combat decisions and operational planning, vendor dependencies could compromise technological sovereignty and mission effectiveness.

Historical context and evolution

The Department of War has experienced vendor lock-in challenges across multiple technology generations. From mainframe computing in the 1960s to client-server architectures in the 1990s, each technological transition created opportunities for vendors to establish dominant positions through proprietary standards and incompatible implementations (Greenstein, 1997; Opara‑Martins et al. 2016). The current AI revolution presents both familiar patterns and novel challenges.

Unlike previous technology waves (Opara-Martins et al., 2016; Silva et al., 2013), AI platforms create dependencies that extend beyond software interfaces into the realm of intellectual property and algorithmic competence. Machine learning models trained on proprietary platforms may become inseparable from their training environments (Mince et al., 2023; Balkan & Akyüz, 2025), creating deeper forms of lock-in that traditional portability strategies cannot easily address.

Types of AI vendor lock-in

Platform lock-in represents the most obvious form, where training, inference, and deployment capabilities are tied to specific vendor ecosystems (Silva et al., 2013). Cloud providers like Amazon Web Services (AWS), Azure, and Google Cloud offer comprehensive AI/ML services that integrate seamlessly within their platforms while creating friction for cross-platform migration. AWS provides Amazon Bedrock for foundation models, SageMaker for machine learning workflows, and Rekognition for computer vision. Microsoft Azure offers Azure OpenAI Service, Azure Machine Learning, and Cognitive Services. Google Cloud delivers Vertex AI, AutoML, and specialized APIs for natural language processing and computer vision. These proprietary services create dependencies through custom APIs, specialized data formats, and vendor-specific optimization techniques that resist migration to alternative platforms.
Data lock-in emerges when training datasets, feature engineering pipelines, and data preprocessing workflows become optimized for specific vendor formats and storage systems (Opara‑Martins et al., 2016). The effort required to extract, transform, and migrate large-scale training data can create substantial switching barriers.

Model lock-in occurs when AI models become dependent on proprietary frameworks, custom hardware accelerators, or vendor-specific optimization libraries. Models trained using proprietary techniques may resist conversion to open standards, particularly when performance optimization depends on vendor-specific implementations.

Expertise lock-in develops when technical teams become specialized in vendor-specific tools, APIs, and methodologies (Opara‑Martins et al., 2016). The human capital investment required to retrain personnel on alternative platforms creates organizational inertia that reinforces vendor relationships.
These categories track the cloud-computing literature that has examined vendor lock-in for over a decade. Silva et al. (2013) surveyed 721 primary studies and classified the field’s solutions into platforms, APIs, and architectures predominantly aimed at IaaS interoperability, identifying a need to address the socio-technical and business dimensions that purely technical fixes do not reach. Opara-Martins et al. (2016) extended that analysis from a business perspective via a survey of 114 cloud customers, finding that lock-in is exacerbated as workloads migrate from on-premise to cloud and that the most effective mitigations combine contractual instruments with the selection of vendors that adopt standardized formats and APIs. The defense-AI categories above instantiate these long-recognized cloud lock-in patterns, with mission-criticality, classification constraints, and proprietary model artifacts amplifying each.

Defense-specific vulnerabilities

The DoW’s operational environment creates unique vulnerabilities to vendor lock-in. Classification requirements limit the ability to evaluate alternative solutions or share experiences across programs. Security clearance requirements restrict the pool of vendors and technical personnel who can work on sensitive systems.

Mission-critical reliability standards make organizations risk-averse to platform changes that could introduce instability or performance degradation. In defense applications, the potential consequences of AI system failures create powerful institutional and psychological incentives to preserve existing vendor relationships, even when technically superior alternatives become available. Moreover, users often develop familiarity and confidence (Greenstein, 1997) in the unique behaviors, response patterns, and “quirks” of a particular AI model, further reinforcing inertia toward change and cultivating a sense of trust in hallucination rate that is not easily transferred to new systems. Prior research shows that increased exposure to AI systems is a strong predictor of user trust and reliance (Alruwaili et al., 2025; Li et al., 2024).

Long procurement cycles and complex acquisition processes create temporal lock-in, where vendor selection decisions made years earlier continue to constrain technical choices throughout extended development and deployment timelines.

Recent DoW policy explicitly recognizes this threat. The January 2022 Department of Defense (now Department of War) Open Source Software memo warns that “reliance on a particular software developer or vendor due to proprietary restrictions may be reduced by the use of open source software” (U.S. Department of Defense Chief Information Officer 2022). However, the memo astutely notes that vendor lock-in can occur even with open source through expertise dependencies and specialized implementations.

The Chief Digital and AI Office (CDAO) has demonstrated successful vendor-agnostic approaches. During Global Information Dominance Experiments (U.S. Department of Defense Chief Digital and AI Office 2023), CDAO implemented completely vendor-agnostic data integration layers that work across all operational systems regardless of platform. This real-world success proves that ML platform independence is both achievable and operationally viable.

Containerization and orchestration foundations

OCI-compliant containers and Kubernetes provide the fundamental abstraction layer for ML platform independence. Unlike traditional deployment models that tie applications to specific infrastructure, container orchestration creates portable, consistent environments that run across any compliant cluster. For defense ML applications, this means models trained on one vendor’s platform can deploy seamlessly to another’s infrastructure.
Container orchestration addresses several lock-in vulnerabilities simultaneously. Resource management becomes standardized through Kubernetes abstractions, eliminating dependencies on vendor-specific cluster management tools. Service discovery and load balancing operate through Kubernetes native mechanisms rather than proprietary networking solutions. Storage orchestration through Container Storage Interface (CSI) drivers enables data portability across different storage vendors.

ML operations (MLOps) platforms like Kubeflow instantiate established approaches to mitigating vendor lock-in by leveraging standardized APIs, architectures, and orchestration frameworks to improve interoperability and portability across cloud environments (Silva et al., 2013; Opara-Martins et al., 2016). Kubeflow v1.8 delivers Kubernetes-native MLOps with modular component architecture, enabling selective adoption without platform lock-in. The framework supports portable pipeline definitions using platform-neutral Yet Another Markup Language (YAML) formats, allowing workflows to execute across AWS, Azure, Google Cloud, or on-premises environments without modification.

Advanced container security features become essential in defense contexts. Pod Security Policies and Network Policies provide standardized security controls that work consistently across different Kubernetes distributions. Runtime security monitoring through tools like Falco operates independently of the underlying infrastructure provider, ensuring a consistent security posture regardless of the deployment environment.

Graphical processing unit (GPU) and accelerator management become standardized through Kubernetes device plugins. Rather than using vendor-specific APIs for resource allocation, the NVIDIA device plugin provides consistent GPU access across different cloud providers. This approach abstracts hardware dependencies while maintaining performance optimization for compute-intensive ML workloads.

Emerging technologies like Intel’s oneAPI and AMD’s Radeon Open Compute (ROCm) provide additional hardware abstraction layers that reduce dependencies on NVIDIA’s Compute Unified Device Architecture (CUDA) ecosystem. These alternatives enable deployment flexibility across different accelerator types while maintaining algorithmic compatibility.

Open standards and model portability

ONNX (Open Neural Network Exchange) improves portability by providing a universal model representation (Zhao, 2025). With over 1,700 supporting tools and growing ecosystem adoption, ONNX enables seamless conversion between PyTorch, TensorFlow, and other frameworks. For defense applications, this means models developed with one vendor’s tools can deploy using different vendors’ runtime environments without performance degradation.
The 2024-2025 ONNX developments significantly enhance defense relevance. Enhanced support for generative AI models addresses DoW’s growing interest in large language models and multimodal systems. ONNX Runtime Web with WebGPU acceleration enables edge deployment scenarios critical for tactical environments.

MLflow provides vendor-neutral experiment tracking and model management. MLflow 3.0 introduces LoggedModel entities and enhanced GenAI support with 15+ framework integrations, including OpenAI, LangChain, and DSPy. The platform’s open-source architecture with over 800 contributors ensures community-driven development independent of any single vendor.

API standardization and abstraction layers

Representational State Transfer (REST) APIs with OpenAPI specifications provide vendor-neutral interfaces. Rather than using proprietary vendor APIs, implement standard Hypertext Transfer Protocol (HTTP) methods with JavaScript Object Notation (JSON) payloads and OAuth2/OpenID Connect (OIDC) authentication. This approach enables easy integration with multiple vendors while maintaining consistent security and performance characteristics.
Abstraction layer design patterns prevent API lock-in. The adapter pattern converts vendor-specific APIs to common interfaces, while the facade pattern simplifies complex vendor APIs through unified abstraction.

Acquisition reform for AI independence

The traditional DoW acquisition framework, designed for physical systems with long lifecycles, creates systematic vulnerabilities to vendor lock-in in AI procurement. Current procurement timelines of 2–5 years are incompatible with AI development cycles measured in months (U.S. Government Accountability Office, 2023). This temporal mismatch forces programs to commit to vendor platforms before competitive alternatives can emerge or mature.

Secretary Hegseth’s November 2025 acquisition reforms directly address these challenges through structural mandates that fundamentally reshape DoW procurement strategy (Katz 2025). The reforms establish four core contractor requirements: accepting risk and investing in capacity, embracing commercial “85% solutions” over perfect custom implementations, maintaining supply chain resilience through dual-source requirements, and performance-based contracting with financial rewards and penalties (Serbu 2025). For AI procurement specifically, the supply chain resilience requirement mandates maintaining “at least two qualified sources for critical program content” to prevent vendor lock-in situations. This policy elevation transforms vendor independence from an optional best practice to a mandatory structural requirement.

The reforms introduce Portfolio Acquisition Executives (PAEs), replacing traditional Program Executive Offices, with single officials managing multiple related programs and authority to reallocate funds based on performance (Gordon 2025). Four-year PAE terms with compensation tied to delivery speed, competition, and mission outcomes create institutional incentives for vendor-independent architectures. The new Wartime Production Unit establishes “deal teams” negotiating across multiple portfolios simultaneously, with financial incentives for companies increasing production rates and delivery speed. These structural changes prioritize “speed to delivery” as the organizing principle — repeated 25+ times in Hegseth’s speech — making vendor lock-in unacceptable due to the agility constraints it imposes.

Reform requires fundamental changes to acquisition policy and practice. Continuous competition models should replace single-award, long-term contracts. Performance-based contracting should emphasize outcomes rather than specific technical implementations. Agile acquisition approaches should enable rapid pivot between vendors when superior alternatives become available.

The Federal Acquisition Regulation (FAR) provides mechanisms for avoiding vendor lock-in, but implementation requires sophisticated technical understanding that many contracting officers lack (General Services Administration 2024). Training programs should develop acquisition workforce competency in AI vendor independence strategies, particularly in light of the new mandatory dual-source requirements for critical systems. International experience offers useful design references: Zick et al. (2024) examined AI procurement checklists in Canada, Brazil, and Singapore alongside the World Economic Forum’s “AI Procurement in a Box” template, concluding that effective regimes require trained AI experts to apply the checklists, broad scope (closing in-house and small-contract loopholes), and public transparency—all directly relevant to scaling DoW dual-source enforcement beyond a narrow set of flagship programs.

Modular contracting methodology

Modular contracting breaks complex AI projects into interoperable increments, reducing vendor lock-in by enabling multiple vendor engagement. This approach encourages faster delivery while providing more competition opportunities. The DoW Software Acquisition Pathway explicitly supports this methodology for software-intensive systems, including AI/ML platforms (U.S. Department of Defense, 2020).

Successful modular implementation requires careful interface design between contract increments. API specifications must be detailed enough to ensure interoperability while remaining flexible enough to accommodate innovation. Technical standards should be based on open specifications rather than proprietary formats.

Risk allocation becomes critical in modular contracting. Integration risks should be allocated to the party best positioned to manage them, typically the prime contractor or systems integrator. Performance risks should remain with individual module providers to maintain accountability and competition pressure.

Data rights and intellectual property strategy

Government data ownership provides the foundation for vendor independence (OparaMartins, 2016; U.S. Government Accountability Office, 2023). Contract clauses must explicitly state: “The Government shall retain unlimited rights to all training data provided by the Government, including derivative datasets created during contract performance.” This prevents vendors from claiming proprietary rights over government-furnished information.
Model and algorithm rights require specific provisions. Critical language includes: “AI models trained using Government-furnished data shall be delivered with unlimited rights to the Government, including source code, model weights, and training parameters.”

Technical data packages must include sufficient information to enable competitive sustainment. Documentation requirements should specify architecture descriptions, software bill of materials (SBOM), API specifications, test procedures, and operational manuals. Source code should be provided with unlimited rights for all government-funded development.

Intellectual property strategies should distinguish between background IP that vendors bring to contracts and foreground IP developed under contract. Background IP can remain proprietary, provided it does not create lock-in through interface dependencies. Foreground IP developed with government funding should include appropriate rights to ensure competition.

Performance-based contracting for vendor independence

Outcome-based metrics reduce vendor lock-in by focusing on mission results rather than specific technical implementations. Success criteria should be defined in terms of accuracy thresholds, availability requirements, and operational effectiveness rather than vendor-specific features or capabilities.
Service level agreements should include portability requirements. Contracts should specify data export formats, migration assistance obligations, and transition support requirements. Vendors should be required to demonstrate compatibility with open standards and provide evidence of interoperability with alternative solutions.

Incentive structures should reward vendor-independent implementations. Contract vehicles should provide benefits for solutions that exceed portability requirements or demonstrate cross-vendor compatibility. Performance penalties should apply when vendor-specific dependencies create migration barriers.

Government data sovereignty principles

Data ownership strategy forms the cornerstone of vendor independence (Opara-Martins et al., 2016). The CDAO’s vendor-agnostic data integration approach demonstrates that data accessibility across operational systems, regardless of vendor platform, is both technically feasible and operationally essential.

Establishing government data rights at the outset of a contract is essential to ensuring long-term control and transparency (U.S. Department of Defense Chief Information Officer, 2022). Training data, feature engineering artifacts, and derived datasets should remain under government control with clearly defined export mechanisms. Contract language should specify data formats, export procedures, and government rights to derivative works.

Open table formats for analytics independence

Apache Iceberg provides enterprise-grade data lake capabilities with schema evolution, Atomicity, Consistency, Isolation, Durability (ACID) transactions, and time travel features essential for defense applications. Unlike vendor-specific data lake solutions, Iceberg works with Spark, Presto, Trino, and other engines, preventing analytics lock-in (Silva et al., 2013). Delta Lake and Apache Hudi offer similar vendor-neutral approaches to data lake management. These open table formats enable organizations to separate storage from compute, allowing analytical workloads to migrate between vendors without data replication (OparaMartins et al., 2016). Version control and time-travel features support audit requirements while maintaining portability.

Data pipeline portability

Extract, Transform, Load (ETL) pipelines should use vendor-neutral orchestration tools like Apache Airflow or Prefect rather than cloud-specific services. Workflow definitions in these tools can execute across multiple cloud providers with minimal modification (Silva et al., 2013; Abhishek & Siwach, 2024). Data validation and quality checks should use open-source frameworks that operate independently of storage vendors.

Framework-agnostic development approaches

A primary mitigation against framework lock-in is to design models so they can be exported through a vendor-neutral interchange format (Mince et al., 2023). ONNX integration should be planned from project inception rather than added as an afterthought: model architectures should be chosen to convert cleanly to ONNX (ONNX Project, 2019), avoiding framework-specific operations that resist standardization. This is a more realistic posture than maintaining parallel PyTorch and TensorFlow training pipelines, which most teams cannot sustainably do; it concentrates the portability work at the export boundary, where it has the highest leverage.

For programs whose research and operational tracks genuinely require different framework strengths, abstraction layers around training-loop primitives (data loading, distributed training, checkpoint serialization) can preserve framework optionality at moderate cost. The key acquisition principle is that a model’s deployable artifact, not its training framework, should determine portability.

Model versioning and registry strategies

Model registries should use vendor-neutral solutions like MLflow Model Registry rather than cloud-specific services (Marcos-Mercadé et al., 2026). Centralized model management enables tracking model lineage, versioning, and deployment metadata independently of serving infrastructure (Marcos-Mercadé et al., 2026). Model artifacts should be stored in formats that support multiple deployment targets.

Experiment tracking should capture sufficient metadata to reproduce training runs on alternative platforms. This includes dependency specifications, hyperparameters, training data references, and environmental configurations. Comprehensive tracking enables migration of development workflows between vendors without losing institutional knowledge.

Deployment flexibility through serving abstractions

Model serving architectures should abstract deployment details behind common interfaces. Tools like KServe (formerly KFServing) provide Kubernetes-native model serving that operates across cloud providers (Korontanis et al., 2025). Custom prediction APIs can route requests to multiple backend implementations, enabling gradual migration or multi-vendor deployments.

Edge deployment scenarios require particular attention to vendor independence. Models deployed to tactical environments may need to operate without cloud connectivity (Silva et al., 2013). Container-based deployments with embedded runtimes ensure consistent operation regardless of infrastructure provider.

Infrastructure-as-Code for portability

Terraform provides a powerful abstraction layer for designing portable cloud infrastructure across multiple providers (Abhishek & Siwach, 2024). By defining infrastructure using declarative configuration files, Terraform enables consistent deployment patterns whether targeting Amazon Web Services (AWS), Azure, Google Cloud, or on-premises environments, preventing lock-in to vendor-specific infrastructure management tools and deployment processes.

Terraform modules enable vendor-neutral infrastructure definitions through parameterization. Resource definitions for compute instances, storage systems, and networking components use variables that abstract provider-specific details: a compute instance module can specify machine type, disk configuration, and networking through variables that map to different cloud provider resources, so the same configuration can deploy to AWS EC2, Azure Virtual Machines, or Google Compute Engine by changing only the provider and variable values, not the core infrastructure logic. This abstraction extends to higher-level services—load balancers, databases, and object storage can be defined using vendor-neutral resource types that Terraform translates to provider-specific implementations. Organizations can maintain a single infrastructure codebase while deploying to multiple cloud environments, reducing vendor dependencies and enabling rapid migration when requirements change (Abhishek & Siwach, 2024).

The declarative nature of Infrastructure-as-Code creates reproducible environments that document infrastructure dependencies explicitly. Version control of Terraform configurations provides audit trails for infrastructure changes while enabling rollback capabilities that reduce migration risks.

Multi-cloud architecture patterns

Workload distribution strategies prevent single-provider concentration (Abhishek & Siwach, 2024). Allocate ML training to providers with best-in-class compute resources while using different providers for data storage, model serving, or edge deployment. This approach leverages vendor strengths while maintaining optionality and competition.

The Joint Warfighting Cloud Capability (JWCC) provides a framework for multi-vendor cloud usage within DoW (U.S. Department of Defense 2022). Rather than single cloud provider lock-in, JWCC enables leveraging multiple vendors’ capabilities while maintaining consistent security and compliance frameworks.

Vendor lock-in risk taxonomy

Alhosban et al. (2024) and Opara-Martins (2016) cover four main areas of vendor lock-in risk. First is the technical risks that encompass proprietary data formats, vendor-specific APIs, and custom hardware dependencies that create migration barriers. These risks compound over time as systems become more deeply integrated with vendor-specific tools and optimizations. Second, commercial risks include pricing leverage, support dependencies, and roadmap control that vendors can exploit once lock-in is established. Sole-source positioning enables vendors to increase prices, reduce service levels, or discontinue products without competitive pressure. Third, operational risks emerge from personnel training investments, workflow dependencies, and integration complexities that make platform changes operationally disruptive. These risks create institutional inertia that reinforces vendor relationships beyond purely technical considerations. Fourth and finally, strategic risks involve mission capability dependencies that could compromise operational effectiveness if vendor relationships deteriorate. National security implications arise when critical capabilities depend on foreign vendors or companies subject to foreign influence.

Risk measurement and monitoring

Quantitative metrics provide objective assessment of vendor lock-in exposure. Migration cost estimates should include data transfer expenses, retraining requirements, and system integration efforts. Dependency mapping should identify critical path components that would be most difficult to replace.

Switching cost analysis should consider both direct financial impacts and opportunity costs of delayed capability delivery. Risk scoring frameworks should weight different types of dependencies based on their difficulty to mitigate and potential operational impact.

Regular assessment cycles should track lock-in risk trends over time. Automated tools can monitor API usage patterns, data format dependencies, and infrastructure utilization to identify emerging lock-in vulnerabilities before they become critical. Recent work in this direction includes Alhosban et al. (2024), who propose a Cloud Vendor Lock-in (CVL) prediction framework that aggregates weighted dependency factors—service costs, data-transfer expense, security features, compliance adherence, scalability, and integration depth—into a quantitative dependency score and ranks providers accordingly; the same factor structure transfers cleanly to defense ML procurement, where compliance and integration depth dominate.

Mitigation strategies by risk type

Technical mitigation focuses on maintaining alternative implementation paths and avoiding proprietary dependencies. Abstraction layers should isolate vendor-specific functionality behind standardized interfaces. Regular portability testing should verify that systems can operate with alternative vendors.

Commercial mitigation requires maintaining competitive vendor relationships and avoiding sole-source dependencies. Multiple vendor strategies should distribute risks across competing providers. Competitive benchmarking should identify alternative solutions before switching becomes necessary.
Operational mitigation involves cross-training personnel on multiple platforms and maintaining documentation that enables vendor transitions. Standard operating procedures should minimize dependencies on vendor-specific knowledge or tools.

Strategic mitigation requires alignment between technical architecture decisions and broader national security objectives. Critical capability assessments should identify dependencies that require government control or domestic sourcing.

An implementation roadmap is illustrated in Figure 1 and then explained in detail.

Figure 1: Implementation Roadmap

Phase 1: Assessment and foundation (0-6 months)

Conduct comprehensive vendor lock-in risk assessment of existing AI/ML implementations. Evaluate current systems for proprietary dependencies, data export capabilities, and migration costs. Document baseline measurements for switching costs, technical debt, and capability gaps that would emerge during vendor transitions.

Establish containerization standards for all new ML deployments. Adopt Open Container Initiative (OCI)-compliant container best practices with proper resource management, security scanning, and multi-architecture support. Deploy container registries that support multiple cloud providers and on-premises environments.

Develop vendor neutrality policies and procedures. Create technical review processes that evaluate new procurements for lock-in risks. Establish architecture review boards with authority to reject solutions that create unacceptable vendor dependencies.

Phase 2: Architecture standardization (6-18 months)

Develop Infrastructure-as-Code templates using Terraform for consistent multi-cloud deployments. Create reusable modules for common ML infrastructure patterns including compute clusters, storage systems, and networking configurations. Test template portability across different cloud providers and government cloud environments.

Implement API-first architecture standards for all AI/ML services. Establish OpenAPI specifications, authentication frameworks, and versioning strategies that enable interoperability across different vendor platforms. Deploy API gateways that can route traffic between multiple backend providers.

Create reference architectures for common AI/ML use cases that demonstrate vendor independence principles. Publish implementation guides that show how to achieve mission capabilities using open standards and multiple vendor options.

Phase 3: Full vendor independence (18+ months)

Achieve seamless workload migration capabilities between different cloud providers and on-premises environments. Implement automated testing frameworks that regularly verify migration capabilities and identify potential lock-in issues. Conduct quarterly migration exercises to validate portability capabilities.

Deploy multi-vendor AI/ML platforms that can utilize different providers simultaneously for training, inference, and data storage. Implement automated failover capabilities that can shift workloads between vendors in response to service disruptions or performance issues.
Establish centers of excellence for vendor independence that can provide expertise and support to programs across the DoW. Create training programs that develop organizational competency in vendor neutrality strategies and implementation approaches.

Continuous improvement and governance

Implement governance frameworks that monitor vendor independence metrics across all AI/ML programs. Establish reporting requirements that track lock-in risks and mitigation progress. Create incentive structures that reward program offices for maintaining vendor neutrality.

Develop community of practice networks that share experiences, lessons learned, and best practices across the DoW. Participate in industry standards organizations to influence the development of open standards that support government requirements.

Maintain technology watch capabilities that identify emerging vendor lock-in risks and opportunities for improving platform independence. Regular assessment of commercial AI/ML landscape should inform strategic decisions about technology adoption and vendor relationships.

CDAO Global Information Dominance Experiments

The Chief Digital and AI Office’s Global Information Dominance Experiments (GIDE) demonstrate successful implementation of vendor-agnostic AI architectures at operational scale (U.S. Department of Defense Chief Digital and AI Office 2023). CDAO implemented data integration layers that work across all operational systems regardless of vendor platform, processing data from over 50 different sources using standardized interfaces.
The GIDE architecture achieves vendor independence through several key design decisions. Data ingestion uses open standard APIs that can accommodate multiple vendor formats without creating dependencies. Processing pipelines run in containerized environments that can execute across different cloud providers. Output formats follow open specifications that enable consumption by multiple analytical tools.

Performance metrics from GIDE operations show that vendor independence does not compromise operational effectiveness. Processing latencies remain within acceptable bounds for tactical decision-making. System availability exceeds 99.5% across multiple vendor environments. Cost efficiency improves through competitive sourcing and workload optimization across providers.

Army Enterprise Cloud initiatives

The Army’s transition from legacy information technology (IT) infrastructure to cloud-based capabilities provides insights into large-scale vendor independence implementation (U.S. Army CIO/G-6 2023). The Army avoided single-cloud dependencies by implementing multi-cloud strategies that distribute workloads across AWS, Microsoft Azure, and Google Cloud environments.

Technical implementation challenges included data synchronization across multiple providers, consistent security policy enforcement, and workload scheduling optimization. Solutions involved developing cloud-agnostic management layers, standardized security frameworks, and intelligent workload placement algorithms.

Operational benefits include improved system resilience through geographic and vendor diversification, cost optimization through competitive pricing, and innovation acceleration through access to best-of-breed capabilities from multiple providers.

Navy AI modernization program

The Navy’s approach to AI implementation emphasizes “buying operational outcomes, not AI,” which naturally aligns with vendor independence strategies by prioritizing capability delivery over platform specifications (U.S. Government Accountability Office, 2023). This philosophy prevents vendor lock-in by focusing procurement on mission results rather than specific technical implementations.

Implementation involves performance-based contracting that specifies accuracy requirements, availability targets, and operational effectiveness metrics while leaving technical implementation details to vendor discretion. Contract terms include portability requirements and data rights provisions that prevent vendor lock-in.

Results demonstrate that outcome-based procurement can achieve superior mission effectiveness while maintaining vendor independence. Competition for follow-on contracts remains robust because vendors cannot rely on lock-in strategies to maintain market position.

Quantum computing implications

The emergence of quantum computing platforms creates new vendor lock-in risks that traditional mitigation strategies may not address. Quantum algorithms often require specific hardware architectures, creating deep dependencies between software and quantum processors from particular vendors (Kumaresan et al., 2026). Mitigation strategies should focus on developing quantum abstraction layers that can compile algorithms for different quantum architectures. Standard quantum instruction sets could enable portability between vendors, similar to how instruction set architectures enable software portability across classical processors. International cooperation on quantum computing standards becomes essential for maintaining competitive markets and preventing concentration among a small number of quantum computing vendors.

Edge AI and tactical considerations

The proliferation of AI capabilities at tactical edge locations creates unique vendor independence challenges. Limited connectivity, resource constraints, and security requirements at edge locations may force reliance on integrated vendor solutions that resist modularity (Nilsson et al., 2024). Vendor independence strategies for edge AI must emphasize local autonomy and vendor-neutral model formats that can operate without cloud connectivity. Container-based deployment models become essential for maintaining consistency between edge and cloud environments. Standards development for edge AI interoperability should address resource-constrained environments, intermittent connectivity, and security requirements unique to tactical operations.

AI regulation and compliance implications

Emerging AI regulation frameworks may create new forms of vendor lock-in through compliance requirements that favor large vendors with extensive legal and regulatory capabilities. Small vendors may be unable to meet complex compliance requirements, reducing competition and increasing lock-in risks (Zick et al., 2024).

DoW should engage actively in AI regulation development to ensure that compliance frameworks support competitive markets rather than creating barriers to entry for innovative vendors. Technical standards should be based on open specifications rather than proprietary implementations (Silva et al., 2013; Opara‑Martins et al., 2016). International coordination on AI regulation becomes essential to prevent regulatory arbitrage that could force dependence on foreign AI vendors who operate under different regulatory frameworks (Zick et al., 2024).

Achieving ML platform independence requires a comprehensive strategy combining technical architecture, procurement practices, and organizational culture change. The DoW’s unique requirements – security, reliability, and mission criticality – make vendor independence both more challenging and more essential than in commercial environments.

Secretary Hegseth’s November 2025 acquisition reforms have transformed vendor lock-in avoidance from an aspirational goal to a mandatory requirement, establishing dual-source mandates as a core structural principle of DoW procurement (Hegseth 2025). The technical and procurement strategies outlined in this paper directly enable compliance with these new policy mandates. Containerization, ONNX standardization, MLflow adoption, and Infrastructure-as-Code provide the technical foundation for maintaining “at least two qualified sources for critical program content,” while modular contracting, performance-based acquisition, and data rights provisions create the procurement framework necessary for competitive multi-vendor environments.

Success demands commitment to open standards, multi-vendor strategies, and government data sovereignty. The technical approaches outlined provide concrete steps toward platform independence, but must be implemented within broader organizational and policy frameworks that support competitive markets. The new acquisition reform structure, including Portfolio Acquisition Executives with performance incentives tied to competition and speed, creates institutional alignment with vendor independence objectives that have historically been absent from DoW procurement.

The case studies presented demonstrate that vendor independence is achievable at operational scale without compromising mission effectiveness. The CDAO GIDE program, Army cloud initiatives, and Navy AI modernization efforts show different approaches to maintaining competitive vendor relationships while delivering superior operational capabilities. These implementations validate that the dual-source requirements mandated by current policy are technically feasible and operationally advantageous.

Looking forward, emerging technologies like quantum computing and edge AI will create new vendor lock-in challenges that require proactive standards development and architecture planning. The DoW’s investment in vendor independence capabilities aims to address these challenges while maintaining technological leadership and operational effectiveness.

The path to vendor independence requires sustained commitment from technical teams, acquisition professionals, and senior leadership. Organizations that successfully implement these strategies will maintain competitive advantage through access to innovation from multiple vendors while avoiding the risks and limitations of vendor lock-in. With vendor independence now a core structural requirement of DoW acquisition policy, the transformation outlined in this paper has moved from optional best practice to mission-critical necessity. The stakes for national security make this transformation essential for maintaining technological sovereignty in an increasingly complex threat environment.

Abhishek, and Vikas Siwach. 2024. “Evaluating Vendor Lock-In and Service Availability Risks in Multi-Cloud Deployments.” International Journal of Innovative Research in Technology. https://ijirt.org/publishedpaper/IJIRT180346_PAPER.pdf .

Alhosban, Amal, Saichand Pesingu, and Krishnaveni Kalyanam. 2024. “CVL: A Cloud Vendor Lock-in Prediction Framework.” Mathematics 12 (3): 387. https://doi.org/10.3390/math12030387.

Alruwaili, Reshaa F., Abdullah A. Alasmari, Hussien Tash Niyazi, I. K. Youssef, Hanan Aifan, and Somia A. Asklany. 2025. “Modeling Public Trust in AI Cognitive Capabilities Using Statistical and Machine Learning Approaches.” Scientific Reports 15: 39856. https://doi.org/10.1038/s41598-025-23447-4 .

D. Balkan and G. A. Akyüz, 2025. “Artificial intelligence (AI) and machine learning (ML) in procurement and purchasing decision-support: A taxonomic literature review,” Artificial Intelligence Review 58(341). https://link.springer.com/article/10.1007/s10462-025-11336-1 .

General Services Administration. 2024. Federal Acquisition Regulation (FAR). https://www.acquisition.gov/far/.

Gordon, Chris. 2025. Pentagon Fundamentally Reshaping Weapons Acquisitions Under Hegseth. Air & Space Forces Magazine. https://www.airandspaceforces.com/hegseth-acquisitions-weapons-pentagon/.

Greenstein, Shane M. 1997. Lock-in and the Costs of Switching Mainframe Computer Vendors: What Do Buyers See? Industrial and Corporate Change 6 (2): 247–273. https://doi.org/10.1093/icc/6.2.247 .

Hegseth, Pete. 2025. Defense Acquisition Reform Speech at National War College. U.S. Department of Defense.

Katz, Justin. 2025. Hegseth Presses Defense Execs to Move Faster, in Speech Laying Out Sweeping Acquisition Changes. Breaking Defense. https://breakingdefense.com/2025/11/hegseth-presses-defense-execs-to-move-faster-in-speech-laying-out-sweeping-acquisition-changes/.

Korontanis, Ioannis, Athina Zacharia, Antonios Makris, Maria Pateraki, and Konstantinos Tserpes. 2025. “Streamlining ML Training in Kubernetes: An MLOps Architecture with Kubeflow.” Proceedings of the 15th International Conference on the Internet of Things (IoT 2025). https://doi.org/10.1145/3770501.3771304 .

Kumaresan, Poornima, Shwetha Singaravelu, Lakshmi Rajendran, and Santhosh Sivasubramani. 2026. “Eliminating Vendor Lock-In in Quantum Machine Learning via Framework-Agnostic Neural Networks.” arXiv preprint arXiv:2604.04414. https://arxiv.org/abs/2604.04414 .

Li, Yugang, Baizhou Wu, Yuqi Huang, and Shenghua Luan. 2024. “Developing Trustworthy Artificial Intelligence: Insights from Research on Interpersonal, Human-Automation, and Human-AI Trust.” Frontiers in Psychology 15: 1382693. https://doi.org/10.3389/fpsyg.2024.1382693 .

MarcosMercadé, Jon, Unai LopezNovoa, and Mikel Egaña Aranguren. 2026. “An Empirical Evaluation of Modern MLOps Frameworks.” arXiv preprint arXiv:2601.20415. https://arxiv.org/abs/2601.20415 .

Mince, Fraser, Dzung Dinh, Jonas Kgomo, Neil Thompson, and Sara Hooker. 2023. “The Grand Illusion: The Myth of Software Portability and Implications for ML Progress.” Advances in Neural Information Processing Systems 36. https://doi.org/10.48550/arXiv.2309.07181 .

Nilsson, Jacob, Saleha Javed, Kim Albertsson, Jerker Delsing, Marcus Liwicki, and Fredrik Sandin. 2024. “AI Concepts for System of Systems Dynamic Interoperability.” Sensors 24 (9): 2921. https://doi.org/10.3390/s24092921 .

ONNX Project. 2019. “ONNX: Open Neural Network Exchange — An Open Standard for Machine Learning Interoperability.” https://onnx.ai/ .

Opara-Martins, Justice, Reza Sahandi, and Feng Tian. 2016. “Critical Analysis of Vendor Lock-in and Its Impact on Cloud Computing Migration: A Business Perspective.” Journal of Cloud Computing: Advances, Systems and Applications 5 (4). https://doi.org/10.1186/s13677-016-0054-z.

Serbu, Jared. 2025. Hegseth Unveils Transformation of DoD Acquisition System. Federal News Network. https://federalnewsnetwork.com/defense-news/2025/11/hegseth-unveils-transformation-of-dod-acquisition-system/.

Silva, Gabriel C., Louis M. Rose, and Radu Calinescu. 2013. “A Systematic Review of Cloud Lock-in Solutions.” Proc. IEEE 5th Int. Conf. On Cloud Computing Technology and Science (CloudCom), 363–68. https://doi.org/10.1109/CloudCom.2013.119.

U.S. Army CIO/G-6. 2023. Army Enterprise Cloud Strategy and Implementation. https://www.army.mil/ecma.

U.S. Department of Defense. 2020. Operation of the Software Acquisition Pathway (DoDI 5000.87). https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500087p.PDF.

U.S. Department of Defense. 2022. Joint Warfighting Cloud Capability (JWCC): Multi-Cloud Strategy for DoD. https://www.defense.gov/News/Releases/Release/Article/3239378/department-of-defense-announces-joint-warfighting-cloud-capability-procurement/.

U.S. Department of Defense Chief Digital and AI Office. 2023. Global Information Dominance Experiments (GIDE): Demonstrating AI-Enabled Decision Advantage. https://www.defense.gov/News/Releases/Release/Article/3282376/dod-chief-digital-and-artificial-intelligence-office-hosts-global-information-d/.

U.S. Department of Defense Chief Information Officer. 2022. Software Development and Open Source Software (DoD Memorandum). https://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareDev-OpenSource.pdf.

U.S. Government Accountability Office. 2021. IT Modernization: USDA Needs to Improve Oversight of Farm Production and Conservation Mission Area. https://www.gao.gov/products/gao-21-512.

U.S. Government Accountability Office. 2023. Artificial Intelligence: DOD Needs Department-Wide Guidance to Inform Acquisitions (GAO-23-105850). https://www.gao.gov/products/gao-23-105850.

Weber, Max. 1930. The Protestant Ethic and the Spirit of Capitalism. Charles Scribner’s Sons (translation).

Zhao, Silin. 2025. “Improving Portability and Interoperability of Deep-Learning Workloads Using ONNX.” MSc Thesis, University of Göttingen

Zick, Tom, Mason Kortz, David Eaves, and Finale Doshi-Velez. 2024. “AI Procurement Checklists: Revisiting Implementation in the Age of AI Governance.” arXiv Preprint arXiv:2404.14660. https://arxiv.org/abs/2404.14660.