Air-Gapped and On-Prem Modernization

Part 5 ended on an honest caveat: most on-prem workloads can reach public cloud, but some cannot. This part is about those. In defense, critical infrastructure, certain financial and healthcare systems, and any environment governed by classification or hard data-residency rules, there are systems that are isolated from external networks on purpose — and required to stay that way. They are often the oldest and most critical systems an organization runs, which means they need modernizing as much as any workload in the estate. The public-cloud playbook simply doesn’t apply to them. This part is about modernizing systems that can’t leave the building.

What “air-gapped” actually means here

An air-gapped system is isolated from external networks — physically, logically, or both — so that data cannot flow to or from the outside. The isolation is the control. A connected-but-restricted system can sometimes reach a private cloud over a controlled link; a true air gap cannot reach anything beyond its boundary, by design.

The practical consequences for modernization are specific:

• No public cloud. The managed databases, elastic compute, and serverless conveniences the rest of this series assumes are off the table. The target is private cloud or modern on-premises infrastructure inside the boundary.
• No external tooling round-trips. Code and data can’t be shipped to an outside service for analysis, build, or validation. Whatever modernizes the system has to operate within the air gap.
• No casual updates. Patches, dependencies, and artifacts cross the boundary through a controlled process, not a package manager reaching the internet. The supply chain itself is part of the threat model.

Not every restricted system is truly air-gapped, and the difference decides how much of the public-cloud playbook you keep. It helps to place your own workload on the spectrum before you scope the work, because a connected-but-restricted system has options a true air gap does not.

Environment	External connectivity	Managed cloud services	Operating burden	Typical driver
Public cloud	Full	Yes	Lowest	The default when policy allows it
Private cloud, connected	Controlled link	Some, plus self-run	Moderate	Data residency and control
Modern on-prem, connected	Restricted	Self-run	Higher	Latency, control, or policy
Air-gapped on-prem	None, by design	Self-run inside the boundary	Highest	Classification, regulation, or a disconnection mandate

The further down the table a workload sits, the fewer conveniences you inherit and the more you assemble yourself. The method does not change as you descend. The operating envelope does. Everything below assumes the bottom row, the strictest case, because a method that holds inside a true air gap holds everywhere above it too.

The constraint is the environment, not the method

Here is the reassuring part, and the load-bearing point of this entire chapter: modernization is about how a system is built, not where it runs. The incremental, parity-first method works identically inside an air gap. You still modernize one slice at a time behind a strangler facade. You still prove each slice produces identical results before it carries live load through a parity gate. You still capture the undocumented behavior as durable documentation. None of that requires a public cloud — it requires discipline, and discipline travels anywhere.

What changes is the target and the toolchain’s operating envelope. The target architecture is designed for the infrastructure you’re actually permitted to use — private cloud, modern on-prem, the approved runtime — rather than a hyperscaler’s services. And the analysis and validation run within the boundary the data must never cross, rather than sending anything outside it. The method adapts to the constraint; it does not ask you to relax the constraint.

Modernizing without the cloud’s conveniences

Stripped of managed services, you rebuild a few things the public cloud would have handed you — but the modern properties are still achievable on-prem:

Cloud convenience	Air-gapped equivalent
Managed database	Modern self-hosted database, operated by the team
Elastic autoscaling	Capacity planned for the workload’s real bounds
Provider observability	Self-hosted metrics, logging, tracing stack
Managed CI/CD	Pipeline running inside the boundary
Provider identity	Internal identity and access management

The target architecture’s goals are unchanged from the rest of this series — modular and testable, observable by default, built on a stack engineers actually want to work in, changeable for the next decade. You simply assemble those properties from components you run yourself instead of services you rent. It is more operational work, and the trade is deliberate: you accept it because the isolation is non-negotiable.

How analysis and validation work inside the gap

The two parts of the method that sound like they need external services — AI-accelerated discovery and parity validation — are exactly the parts that have to respect the boundary most carefully. The principle is simple: the work comes to the data, not the data to the work. Discovery reads the codebase, configuration, and data inside the environment and captures what it finds there. Validation runs the modern slice beside the legacy inside the same boundary, comparing outputs on real inputs, with nothing crossing out. The proof you get is the same proof — functional parity, data integrity, performance — produced under the controls the environment demands.

This is what “regulated and air-gapped environments supported” has to mean in practice: not a relaxed version of the method, but the full method operated within constraints that never bend.

A slice migration inside the gap, concretely

Stripped of jargon, here is what one slice looks like when the system can’t leave the building. Say the workload is a thirty-year-old claims engine on an unsupported runtime, isolated by classification. The first slice is a single bounded capability — say, the eligibility check — chosen because it’s self-contained and high-value.

Discovery reads the existing code and data in place and writes down exactly what the eligibility check does, including the three exceptions nobody on the current team can explain. The modern slice is built against that captured behavior and deployed onto the approved on-prem infrastructure, beside the legacy. A facade routes eligibility checks to both, compares the results on real cases, and surfaces any divergence as a discrepancy to resolve — all inside the boundary, nothing crossing out. When the new slice matches the legacy across the full range of real inputs, traffic shifts to it gradually; the legacy eligibility path is decommissioned only once the modern one has carried production load cleanly. Then the next slice begins.

Nothing in that sequence required a public cloud. It required reading the system honestly, proving equivalence before trusting it, and a facade to make the switch reversible — and all three work identically whether the target is a hyperscaler or a server rack the data is legally bound to.

The supply chain is part of the boundary

One constraint deserves its own attention, because teams underestimate it. In a connected environment, dependencies — libraries, base images, patches — flow in continuously and almost invisibly. Inside an air gap, every one of those artifacts crosses the boundary through a controlled, audited process. That changes how you architect: you favor a smaller, well-understood dependency set you can vet and bring across deliberately, rather than a sprawling tree that assumes a package manager with open internet access. The modern system has to be maintainable under the air gap’s update discipline, not just maintainable in the abstract — which is itself a design constraint worth getting right from the first slice.

Slower, and worth saying so

Air-gapped modernization is slower and more operationally demanding than its public-cloud counterpart, and it is honest to say so. You forgo elasticity you might have wanted. You take on operating burden the cloud would have absorbed. Capacity you would have scaled on demand has to be planned and provisioned. None of that is a reason to avoid modernizing — these systems are frequently the ones whose legacy risk is highest — but it is a reason to scope the work with clear eyes. The payoff is a system that is modern, maintainable, and still inside the boundary it was always required to stay within. The constraint doesn’t disappear; it gets designed into the target from the first slice.

Where this leads

Whether you modernize in public cloud, private cloud, or behind an air gap, one architectural question outlives the migration: how much of your system’s future do you hand to a single provider? Get it wrong and you trade a hardware dependency for a vendor one that’s harder to leave. Part 7, Multi-Cloud and Avoiding Vendor Lock-In, is about designing for portability — so the platform you chose this year doesn’t become the legacy you’re trapped in next.