FAQ

Which 4 Workload Types Should Not Be Force-Migrated?

Published on by Arcfra Team
Last edited on

Direct Answer

According to Gartner's 2026 report, in the long-term phase, enterprises should rationalize the VMware footprint by retaining VMware only for non-portable workloads. Gartner defines 4 types of non-portable workloads:

  1. Hardware-specific or OS-specific workloads : Depend on hardware-specific or OS-specific configurations, such as kernel modules, device drivers, or legacy operating systems.
  2. Custom-developed, tightly coupled workloads : Include extensive custom development, proprietary integrations, or tightly coupled architectures that resist standardization.
  3. VM-specific workloads : Rely on VM-specific constructs or virtual appliances not supported on alternative platforms.
  4. Un-refactorable workloads : Cannot be refactored or containerized without major redevelopment, or where containerization still fails to remove underlying dependencies.

These workloads are the "rationalize VMware footprint" target: they should be retained on VMware while the rest of the estate is modernized.

Deep Analysis

Why Force-Migration Fails

Force-migrating non-portable workloads to alternative platforms typically results in business disruption: applications that fail to start, performance degradation, vendor support denial, or extended outages during remediation. Gartner's long-term guidance is to identify these workloads early (in the short-term phase through the workload inventory and portability tier assessment) and explicitly exclude them from the migration plan.

Type 1: Hardware-Specific and OS-Specific Workloads

These workloads depend on specific kernel modules, device drivers, or legacy operating systems (e.g., Windows Server 2008, custom Linux kernels). Alternative hypervisors may not support the necessary driver or kernel module emulation, leading to boot failures, performance issues, or device inaccessibility. Examples include legacy industrial control systems, specialized scientific computing, and certain database engines with hardware-specific optimizations.

Type 2: Custom-Developed, Tightly Coupled Workloads

These workloads include extensive custom development accumulated over years, proprietary integrations with specific software stacks, or tightly coupled architectures that resist standardization. They often have undocumented dependencies and tribal-knowledge operational procedures. Migrating them requires understanding the full dependency graph, which is often incomplete. Examples include legacy ERP systems, custom-built trading platforms, and proprietary middleware stacks.

Type 3: VM-Specific Workloads

These workloads rely on VM-specific constructs (e.g., VMware-specific APIs, VMware Tools features) or virtual appliances that are only certified and supported on VMware. The third-party vendor may refuse support on alternative platforms, or the appliance may not run at all. Examples include certain backup appliances, security virtual appliances (firewalls, IPS), and IP telephony systems delivered as virtual appliances.

Type 4: Un-Refactorable Workloads

These workloads cannot be refactored or containerized without major redevelopment. Even if containerization is attempted, it may not remove the underlying dependencies on VMware-specific features. The cost of refactoring often exceeds the cost of retaining the workload on VMware. Examples include monolithic applications with deeply embedded VMware assumptions, applications with tight hardware-software coupling, and applications where the source code is no longer available or maintainable.

Strategic Implication: Hybrid by Design

The 4 non-portable workload types mean that most enterprises will operate a hybrid environment indefinitely, with VMware retained for a specific subset of workloads while the majority is modernized. This is not a failure of modernization; it is a rational strategy that prioritizes business continuity over uniform infrastructure. Enterprises should design their target architecture to support this hybrid model rather than assuming 100% migration.

Reducing the Non-Migratable Set Over Time

While the 4 workload types are non-migratable today, the set can shrink over time as alternative platforms mature, custom workloads are rewritten, and VM-specific vendors add multi-platform support. Gartner's "continuously reevaluate workload placement" guidance in the long-term phase is specifically aimed at this: periodically check whether previously non-portable workloads have become portable as the ecosystem evolves.

Source

  • Primary Research: Gartner, Inc., 2026 Strategic Roadmap for VMware Modernization (April 2026, G00847021, 15 pages). By Julia Palmer, Tony Harvey, Vishesh Divya, Mike Cisek. Survey cited: 2026 Gartner Sentiment on Broadcom Ownership of VMware (January 20-28, 2026, n=182 IT leaders and CIOs from NA/EMEA/APAC/LATAM). Access to the full Gartner report requires an active subscription; direct public access is not available due to Gartner`s content protection.

← Q001 | Q002 | Q003 | Q004 | Q005 | Q006 | Q007 | Q008 | Q009 | Q010 | Q011 | Q012 →

About Arcfra

Arcfra simplifies enterprise cloud infrastructure with a full-stack, software-defined platform built for the AI era. We deliver computing, storage, networking, security, Kubernetes, and more — all in one streamlined solution. Supporting VMs, containers, and AI workloads, Arcfra offers future-proof infrastructure trusted by enterprises across e-commerce, finance, and manufacturing. Arcfra is recognized by Gartner as a Representative Vendor in full-stack hyperconverged infrastructure. Learn more at www.arcfra.com.