Cloud vs On-Premises vs Air-Gapped ERP: Choosing a Deployment Model

Where your ERP runs used to be an IT preference. For a manufacturer in 2026 it is a compliance decision, a resilience decision, and increasingly an AI decision, because the deployment model determines where your data can live, what happens when the internet drops mid-shift, and whether the intelligence in your system can legally see the data it needs. Most ERP vendors will tell you the answer is cloud, because cloud is the only thing they sell. The honest answer is that the right model falls out of a handful of questions about your data, your contracts, and your shop - and this guide walks through them in the order that actually decides the outcome.

The three models, defined plainly

Cloud (SaaS) means the vendor hosts the software and your data in their infrastructure, you reach it over the internet, and the vendor handles patching, backups, and uptime. It is the fastest to stand up and the lightest on your IT staff.

On-premises means the software runs on servers you own or control, inside your facility or your private data center. You (or a managed service provider) run the infrastructure. Your data never leaves an environment you administer, but it still connects to the outside world for updates, integrations, and vendor support.

Air-gapped means on-premises with the connection cut: no external calls, no cloud dependencies, no data leaving the boundary at all. Updates arrive by controlled transfer, not download. It is the model for classified-adjacent work, for the strictest ITAR interpretations, and for facilities where the network boundary is itself a controlled perimeter.

These are genuinely different operating postures, not three price points for the same thing.

Question one: where is your data allowed to live?

Start with the data boundary, because it can eliminate options before any other factor gets a vote.

If you handle ITAR-controlled technical data - export-controlled drawings, models, specifications - that data must be protected from foreign-person access. A generic public cloud raises immediate questions: where are the data centers, who administers them, and can the vendor’s offshore support staff see your tenant? Some cloud offerings answer these questions acceptably; many cannot. Shops doing sustained defense work often conclude that an ITAR-aware ERP deployed on-premises is simpler to defend than a stack of cloud attestations, and the most conservative programs require a full air-gapped deployment where the question of external access is settled by architecture instead of by contract language.

If you handle CUI under CMMC 2.0, the calculus is different but related. CMMC does not forbid cloud - it requires that every system storing, processing, or transmitting CUI meets the NIST SP 800-171 controls, and cloud services in scope generally need to demonstrate an equivalent bar. What CMMC punishes is sprawl: CUI scattered across a cloud ERP, email, shared drives, and shop-floor PCs makes your assessment scope enormous. A deployment model that concentrates CUI inside one well-controlled boundary - which can be a properly configured cloud enclave or an on-premises system - shrinks the problem. If you are early in that process, our guide to CMMC 2.0 requirements for manufacturers covers the levels and controls, and a platform built for CMMC 2.0 Level 2 readiness should support whichever boundary you choose rather than forcing one.

If you have no regulated data at all, the boundary question relaxes and the decision shifts to the operational factors below.

Question two: what can your IT organization actually run?

On-premises and air-gapped deployments hand you responsibilities the cloud vendor would otherwise carry: server hardware, OS patching, backup and restore, disaster recovery, and physical security of the room the servers sit in. A shop with one overworked IT generalist should be honest about this. An ERP that is down because nobody tested the restore procedure is worse than a cloud dependency. The mistake runs in both directions, though: shops sometimes choose cloud to avoid IT work, then discover that identity management, integration upkeep, and vendor change windows are still their problem. No deployment model removes the need for someone competent to own the system. The realistic question is whether that person manages infrastructure or manages a vendor.

Question three: what happens on the floor when the connection drops?

An ERP is not a back-office system anymore. When operators clock onto jobs, record inspection results, and pull work-to lists from the scheduling module at the machine, the ERP is in the production path, and its availability is a production constraint. Cloud deployments put an internet connection between your operators and their instructions. For a plant with reliable fiber and a tolerance for occasional read-only degradation, that risk is manageable. For a plant in a rural industrial park with one fragile ISP, or a facility where a stopped line costs real money by the minute, local hosting keeps the system on the same wire as the machines. Latency matters less than people fear for transactional work, but availability matters more than cloud vendors admit. Ask any vendor what the shop floor can still do during a WAN outage, and listen for a specific answer.

Question four: where does the AI run?

This is the newest factor and the one buyers most often miss. If your ERP has embedded AI - agents that watch schedules, flag quality trends, draft purchase orders - that AI needs to read your production data. In most cloud AI architectures, it does so by sending data to an external model endpoint. For a shop with ITAR technical data or CUI in the system, that can mean your compliance boundary silently extends to a third-party model provider, which is exactly the kind of surprise an assessor enjoys finding.

The alternative is AI that runs where the data lives. An on-premises deployment can host models locally, and a genuinely air-gapped deployment must - embedded AI with no external calls at all. Cortrova was built for this constraint: its AI engine can run on on-premises models, so the 65 embedded agents work identically in a sealed environment, and every AI request passes through the same governance pipeline and audit log regardless of deployment. When you evaluate any vendor, ask the question in exactly this form: “Does your AI still work with the internet cable unplugged?” The answer sorts marketing from architecture faster than anything else you can ask, and the details of a vendor’s security model should back it up.

The comparison at a glance

Factor	Cloud	On-Premises	Air-Gapped
Data boundary	Vendor’s infrastructure, defined by contract	Your facility or data center	Your facility, physically isolated
ITAR-controlled data	Requires careful vetting of hosting and personnel	Strong fit with proper access controls	Strongest fit; boundary enforced by architecture
CUI / CMMC scope	Possible with a qualifying enclave; scope needs discipline	Concentrated, well-defined scope	Smallest practical scope
IT burden	Lowest; vendor operates the stack	You run servers, patching, backups	Highest; includes controlled update process
Shop-floor resilience	Depends on internet availability	Survives WAN outages	Fully independent of external networks
Embedded AI	Usually external model endpoints	Can host models locally	Must host models locally; no external calls
Typical fit	Commercial work, distributed sites, lean IT	Regulated work, unreliable connectivity, data control	Defense programs, strict ITAR postures, sealed facilities

How the decision usually lands

Patterns emerge across shops. Commercial manufacturers with no export-controlled work and decent connectivity usually land on cloud and are right to. Defense manufacturers and tier suppliers holding ITAR data usually land on-premises, because it makes the boundary conversation with primes and assessors short. Air-gapped is a smaller population with a non-negotiable requirement, and for them the deciding question is which vendors can deliver full functionality - AI included - inside the gap, because many products degrade into a shell of themselves without their cloud services.

Two cautions before you commit. First, deployment model is not a security guarantee in any direction: a neglected on-premises server is more vulnerable than a well-run cloud tenant, and the controls, access model, and audit coverage matter more than the hosting. Second, pick a vendor that offers more than one model. Contracts change, and the shop that wins its first big defense program should not have to change ERP platforms to take the work. If you are still framing the wider selection, the manufacturing ERP buyer’s guide puts deployment in context with the rest of the evaluation.

Choose the boundary first, confirm the AI respects it, and be honest about who will run the infrastructure. Get those three right and the deployment model stops being a debate and becomes a conclusion.