Manufacturing VDI Modernization: On-Premises, Hybrid, and Cloud Infrastructure Guide for CIOs

Most conversations about VDI modernization in manufacturing treat the decision as a binary — stay on-premises or move to the cloud — and then work backward to justify whichever direction the author prefers.

That framing does not reflect how manufacturing IT actually works. Plant floor workstations, remote engineering teams, legacy industrial applications, and OT-connected users are not versions of the same problem. They are different workloads that belong on different infrastructure placements.

This guide provides a workflow-first framework for making those placements correctly — and covers the full ecosystem you need to execute them: migration tooling, profile management, monitoring, backup, and identity.

The Core Problem: Platform Lock-In

The disruption that pushed manufacturing organizations to re-evaluate their VDI strategy was not caused by on-premises infrastructure failing. It was caused by platform lock-in — the tight coupling between the delivery layer (Citrix Virtual Apps and Desktops, VMware Horizon) and the infrastructure layer (the hypervisor, storage fabric, and management stack underneath it).

When Broadcom restructured VMware’s licensing after the 2023 acquisition — eliminating perpetual licenses, moving to subscription-only bundles, and discontinuing standalone product sales — organizations that had deployed Horizon on vSphere found themselves with no negotiating leverage. They had built their VDI architecture on a stack where every component was controlled by the same vendor. The same dynamic played out with Citrix, where customers on multi-year renewal contracts faced price increases that bore no relationship to the value delivered.

The structural lesson here is not that on-premises is bad or that cloud is better. It is that a VDI delivery layer that is decoupled from the infrastructure underneath it gives you optionality that a tightly coupled stack does not. If your session brokering, access control, and user experience layer can run on your existing VMware estate, on a modern hyperconverged platform, on Oracle Cloud, or on a hybrid combination — and present the same management interface and the same user experience in all cases — then your infrastructure decisions become independent of your VDI platform decisions. That independence is what most manufacturing organizations lacked when the licensing disruption hit.

The Financial and Technical Challenges — Stated Plainly

Before discussing solutions, it is worth naming the pressures clearly. Most manufacturing CIOs are dealing with some combination of the following, and the right modernization path depends on which pressures are actually present in your organization.

Rising Platform Costs With Declining Perceived Value

Both Citrix and VMware Horizon have moved toward subscription licensing with pricing structures that reflect historical market positions rather than current competitive alternatives. Organizations renewing perpetual licenses are facing conversations that can represent a 100–200% increase in annual spend for equivalent functionality.

In manufacturing, where VDI usage is typically narrower than the full enterprise feature set — primarily remote access, application delivery, and plant floor thin client support — the gap between what is being paid for and what is actually used is often significant.

The real question is straightforward: Is the cost of switching platforms less than the cost of staying on the current one over a 3–5 year horizon? That calculation requires a complete cost model, not just a comparison of list prices.

Hardware Refresh Cycles and Their Timing

On-premises VDI infrastructure requires refresh every 4–6 years. When a refresh cycle coincides with a licensing disruption, organizations face a compounded cost event

• Hardware CapEx and licensing restructuring at the same time
• No flexibility to defer either decision independently
• A narrow window where the financial case for migration is clearest

A hardware refresh is both a pressure and a strategic opportunity. It is the moment where rebuilding on-premises, migrating to cloud, or pursuing a hybrid architecture has the strongest financial justification.

Legacy Application Complexity

Manufacturing environments carry more legacy application debt than any other sector. Common constraints include:

• Custom Win32 applications built in the 1990s
• Vendor-supplied industrial software locked to specific Windows versions
• Applications with hardware key or parallel port dependencies
• HMI software validated only on Windows 7 or Windows 10 LTSC

Many of these can be addressed through FSLogix (which isolates application data from the base image, allowing non-persistent pools to behave like persistent ones) or through RemoteApp delivery, which publishes individual applications through a browser session rather than requiring a full desktop.

However, some applications have constraints that no delivery technology can fully abstract — specific OS versions, hardware-level dependencies, or behaviors that break in shared session environments. Identifying these before starting a modernization project is more valuable than any architecture decision.

OT Network Access

Users who access SCADA systems, PLCs, historian platforms, and HMI panels through their VDI session present a constraint that each stack — on-premises, hybrid, and cloud — must solve differently.

The OT network is isolated for technical and regulatory reasons:

• Purdue Model — defines logical segmentation between IT and OT layers
• IEC 62443 — establishes security requirements for industrial automation systems
• NIS2 (Europe) — sets network segmentation expectations for critical infrastructure

Any VDI modernization involving a cloud delivery layer must address how authenticated, monitored access flows from a cloud-delivered session to an isolated OT network — without creating a network path that bypasses that isolation.

Multi-Site Latency Variability

Manufacturing organizations typically have plants, distribution centers, and engineering offices at disparate locations with very different WAN quality profiles. A single infrastructure placement decision cannot serve all of them equally.

Latency thresholds that matter:

A plant on 50 Mbps MPLS, a central campus on dedicated fiber, and a remote distribution center on LTE backup require different infrastructure placement strategies — not a single answer applied uniformly.

Three Infrastructure Stacks — Each Optimized for Different Workloads

The following three stacks represent the primary architecture patterns for manufacturing VDI. They are not mutually exclusive — the most common real-world deployment uses elements of all three, managed from a single platform.

What About Existing VMware Workloads That Cannot Migrate?

If your organization has workloads that are deeply integrated with VMware vSphere or ESXi — and where a hypervisor migration is not currently feasible due to operational risk, application validation requirements, or contractual timelines — Thinfinity integrates directly with VMware as the session host substrate. You replace the Citrix or Horizon delivery layer with Thinfinity, reducing your platform licensing exposure immediately, while leaving the VMware hypervisor in place. The hypervisor migration to VergeIO or OCI can then proceed on a separate timeline, workload by workload, without changing what users see or how IT manages sessions.

This incremental approach is valid and often the most risk-appropriate path for large environments with significant VMware investment. It is not a permanent answer — the goal is to eventually consolidate the infrastructure layer as well — but it is a legitimate and financially rational first step.

The Ecosystem Tools You Need — Regardless of Which Stack You Choose

One of the gaps in vendor-written VDI guides is that they focus entirely on the delivery platform and ignore the broader ecosystem of tools required for a production VDI environment to work reliably. The following tools are not optional components — they are required pieces of a complete architecture, and choosing them well is as important as choosing the VDI delivery platform.

These tools do not replace the VDI delivery platform — they work alongside it. A complete architecture decision includes evaluating how your chosen VDI platform integrates with each of these components, not just whether the platform delivers sessions correctly.

Workflow-First Decision Framework

The most reliable approach to infrastructure planning is to classify workloads first and let the classification determine the infrastructure placement. The following framework maps common manufacturing VDI workflow types to their appropriate stack and explains the reasoning behind each placement.

Completing this classification for your specific application portfolio — with tested latency measurements, not assumptions — is the most valuable technical work you can do before any architecture decision.

Cost Reduction Without Sacrificing Features

A persistent concern in VDI modernization is whether moving away from Citrix or VMware Horizon means accepting a degraded feature set. This concern is understandable — both platforms have mature capability sets built over decades — but it is often overstated when applied to the delivery layer rather than the infrastructure layer.

The core capabilities required for manufacturing VDI — session-based and persistent desktop delivery, RemoteApp and published application support, GPU acceleration, multi-monitor support, RDC and VNC protocol support, AD/SSO integration, RBAC, autoscaling, session recording, USB and peripheral redirection, and a unified management interface — are available in modern VDI delivery platforms that are not priced for legacy market dominance. Feature parity at the delivery layer is real; what the modern platforms have improved is the operational complexity required to achieve those features, and the infrastructure flexibility underneath them.

Where Cost Reduction Actually Comes From in Each Stack

On-premises (Thinfinity + VergeIO):

VergeIO’s ultraconverged infrastructure consolidates hypervisor, storage, and networking into a single software stack running on commodity hardware. Organizations migrating from VMware report:

• 40–60% improvement in hardware utilization: VergeIO eliminates the resource overhead of VMware’s management VMs, vSAN storage fabric, and NSX networking layer
• Reduced delivery licensing cost: replacing Citrix or Horizon with Thinfinity removes platform licensing while preserving delivery capabilities
• Same or reduced hardware footprint: without requiring a cloud migration

Cloud (Thinfinity + OCI):

OCI compute pricing runs 30–50% below equivalent Azure and AWS instance types. Combined with Thinfinity autoscaling, cloud spend tracks actual peak concurrency rather than total user count.

Example — 400-user plant, three shifts of 130 workers:

• Peak concurrent sessions: ~150 (not 400)
• Cloud spend reflects: 150 instances × 8 hours per shift
• Idle hours: zero — hosts power down after shift end

OCI also includes 10 TB of free monthly data egress per region, which meaningfully reduces network cost for multi-site environments.

Hybrid (Thinfinity + VergeIO + OCI):

The hybrid model captures cost benefits from both layers:

• On-premises handles OT access, latency-sensitive apps, and recently refreshed hardware — at full utilization
• Cloud handles elastic overflow, GPU workloads, and geographically distributed users — on demand
• Single console (Thinfinity Cloud Manager) manages both — the incremental operational cost of a second infrastructure layer is significantly lower than running two separate management systems

Building a Migration Trajectory That Matches Your Organization

The workflow-first framework gives you a target architecture. What most organizations also need is a realistic migration sequence — one that delivers tangible value early, manages risk carefully, and does not assume the organization can absorb a full cutover within an arbitrary deadline.

Where Thinfinity Workspace Fits Into This Architecture

The preceding sections have been deliberately infrastructure-neutral. This section explains specifically what Thinfinity does that is particular to the manufacturing scenarios described above.

One Platform Across All Three Stacks

Thinfinity Workspace runs on VMware vSphere/ESXi, VergeIO, Hyper-V, Proxmox, Oracle Cloud, Azure, AWS, GCP, and others. Thinfinity Cloud Manager provides a single management console across all of them — users connect through one HTML5 portal and are routed to whichever infrastructure hosts their applications.

Why this matters in manufacturing: The realistic answer to a workload placement analysis is almost always hybrid. A platform that manages OT-adjacent workloads on-premises, administrative workloads in the cloud, and VMware-locked workloads on existing vSphere — all from one console — means your IT team trains once and your users see one interface.

FSLogix Integration and Non-Persistent Pool Support

Thinfinity delivers pooled non-persistent desktop sessions that work correctly with FSLogix profile containers. The session host is stateless (fast provisioning, no per-user configuration drift); the user’s profile and personalization persist across sessions through FSLogix containers stored in a shared location.

Why this matters in manufacturing: Shift workers sharing terminals pick up their profile regardless of which session host or physical terminal they log into — with no support overhead on every login..

The OT Access Architecture

For isolated OT networks, Thinfinity’s secondary broker deploys inside the OT segment and initiates outbound-only connections to the primary Thinfinity Gateway — no inbound connectivity from cloud or corporate network into the OT segment is required. Session recording provides the audit trail required by IEC 62443 and NIS2.

Why this matters in manufacturing: Authenticated, monitored access reaches SCADA, HMI, and historian platforms without network bridging or compromising Purdue model segmentation.

Autoscaling Configured for Manufacturing Shift Patterns

Thinfinity Cloud Manager’s autoscaling policies pre-provision session hosts on a schedule aligned to shift start times — typically 20 minutes before — and power down idle hosts after shift end based on session count thresholds.

Why this matters in manufacturing: Cloud compute spend tracks your operational calendar, not a flat always-on count. Combined with OCI reserved instances for baseline capacity and on-demand for peak overflow, the monthly cost becomes predictable and directly tied to your shift schedule.

Monitoring Integration With Datadog

Thinfinity exposes session metrics — login time, active connections, host resource utilization — that integrate with Datadog through OCI’s monitoring stack or direct API, giving operations teams unified VDI and infrastructure observability in one place.

Migration Support Through RackWare

For organizations migrating from VMware, Thinfinity’s session host images are standard VMs — RackWare replicates them to OCI, validates them in parallel, and cuts over during maintenance windows. The Thinfinity management layer stays in place throughout; users experience no change in their portal or access method during the migration.