A year ago, many enterprises were still debating "whether to replace their virtualization with China domestic alternatives"; today, the question has shifted from "whether to" to "which vendor to choose so as not to replace a familiar production environment with a new set of uncertainties."

This shift was not sudden. Following VMware's adjustments to its licensing and service strategies, cost, support, and self-controllable infrastructure all landed on the table simultaneously. Meanwhile, a seemingly easier approach emerged: tossing the question of "which domestic virtualization vendor to choose" to a large language model (LLM), then treating the generated result as the selection conclusion.

LLMs excel at compiling feature lists from vendor websites. However, AI cannot see how many virtual machines you have, how short your backup window is, how IT Application Innovation (ITAI) chips are co-deployed, nor can they run a POC against your live network. Treating recommendation lists as decisions risks mistaking marketing claims for production capabilities.

The starting point for selection is not "which brand does AI recommend," but "which things must the production environment consider before choosing the replacement plan." AI Reference results are fine, but users must consider 5 critical things before deployment. The 5 critical things are as listed:

01  Feature Parity: Live Migration / HA / Scheduling

02  Migratable and Rollbackable: Agentless / Drillable / Rollbackable

03  Post-Switch Evolvability: Cloud and AI Without Starting Over

04  Scenario Coverage Without Additional Platforms: ITAI / Cryptography Assessment / Cloud-Edge / Security

05  Clear Accounting and Team Readiness: Licensing / Hardware Reuse / Team Learning Curve

01 / WHY NOT ASK AI

Why "Asking AI for Recommendations" Can Mislead Your Decision

It's not that LLMs are useless. For organizing public information and listing comparison dimensions, they're quite convenient. The risk arises when you treat "who they recommend" as a conclusion.

First, the models often read materials that vendors themselves produced the most. Independent third-party, seamless replacement, one-cloud-multiple-chips—almost every vendor makes these claims. The model can hardly judge which statement has been validated in production networks and which is merely a website talking point.

Second, the same set of questions, when posed to a different model or phrased differently, often yields different answers. This indicates that the output is closer to "retrieved statements" than to measurements of your environment.

Third, the truly difficult aspects of virtualization replacement are not in spec sheets, but in whether migration can afford downtime, whether rollback is possible, whether operational habits can be sustained, and whether you'll need to buy another cloud platform, another AI stack, another cryptography assessment after the switch.

Therefore, a more prudent approach is: let AI help you formulate questions, not pick vendors for you. The following five gates are what enterprises must answer themselves.

Replace the "Recommendation List" with a "Gate Checklist"

02 / FEATURE PARITY

One: Feature Parity — So Operations Can Keep Up

Teams that have used vCenter for over a decade fear two things: discovering after the switch that live migration, high availability, dynamic scheduling, snapshot, and clone don't align; and that the UI logic is too different, requiring everyone to relearn daily operations.

The positioning of ZStack ZSphere virtualization platformis precisely to make this work. It shares the same engine with ZStack Cloud platform, benchmarks against vSphere's enterprise-grade virtualization features, covers 95%+ of VMware's full-lifecycle VM management capabilities, and retains familiar organizational constructs like distributed switches and port groups, emphasizing that operations require no relearning.

For scenarios such as financial, healthcare, and manufacturing, if there's no short-term need for multi-tenancy or elastic bare metal cloud features, stabilizing the virtualization foundation first is often more practical than going full-cloud in one step. ZSphere covers compute, network, and storage virtualization, and provides backup, disaster recovery, and bare metal management capabilities that can be added as needed; advanced features are unlocked via License upgrades, without deploying a new platform.

Feature parity is the baseline, not the full score. A point often raised in public reviews: some advanced capabilities are difficult to achieve instruction-level equivalence with vSphere and need to be separately evaluated before migration, compensating with application-layer high availability. Categorizing into "must align," "can be substituted," and "acceptable to lack" across three columns is more useful than chasing an all-green spec sheet.

03 / MIGRATION

Two: Migratable, and Rollbackable

Whether replacement can land ultimately comes down to migration. What enterprises really need to ask: Do we need to install agents in VMs? Can we do online sync with a brief final cutover? If it fails, can we roll back to the source platform? Can the original backup strategy still be connected?

ZStack provides an agentless migration tool, ZMigrate, which replicates VMs through VMware APIs with no intrusion on business. The typical rollout cadence: assessment, live-network POC, non-core workload cutover first, core workload cutover later, with rollback windows preserved for each cutover. During the transition, ZCenter can also bring existing VMware environments into the same management view—first achieve unified visibility, then migrate in batches.

Manufacturing: Familiar UX, Hardware Reusable, Agentless Migration

Faced with rising licensing and maintenance costs, replacing the original VMware with ZSphere, combined with SAN storage for a traditional three-tier architecture, can consolidate MES, WMS, AGV, QMS, TPM, and other systems into a unified resource pool. What the team cares about is not another brand change, but that production lines must run 24/7 without interruption.

Financial : Production Zone and Dev/Test Zone Separation

If the live network has evolved beyond virtualization to include networking, operations, and container components, another path is upgrading to a cloud platform rather than just swapping the hypervisor. You can separate the production business zone and dev/test zone into two clusters, consolidating channel systems, customer service, internet-facing business, and R&D resources into a unified resource pool. The paths may differ, but the evaluation criteria are the same: POC first, then batch migration, with core business validated separately.

Note: Cutover duration, concurrency scale, and rollback verification must be tested using your own VMs and your own network. The shortest time achieved in a lab cannot be directly written into a production cutover plan.

04 / EVOLUTION

Three: After the Switch, Can You Still Move Forward?

Many replacement projects stumble in year two: virtualization is replaced, but multi-datacenter management is unwieldy, storage and DR require new infrastructure, and when AI arrives, another platform must be purchased. Today's licensing savings become tomorrow's costs of starting over.

In August 2026, ZStack released ZVF 1.0 (ZStack Virtualization Foundation). It uses ZSphere as the virtualization foundation, introduces ZCenter for multi-environment unified management, integrates ZStone software-defined storage, and explores cross-site continuity with ZLR. Enterprises can start with single-site virtualization, then add modules for management, storage, and disaster recovery as needed, without replacing the foundation at each upgrade.

Figure 2: ZVF Architecture — ZSphere as the Virtualization Foundation

ZSphere handles in-site VM operations; ZCenter handles cross-environment unified governance.

ZCenter adopts a MoM (Manager of Managers) layered architecture: the upper layer provides unified entry, users, authorization, and operations views; the lower layer has each ZSphere continuing to handle local compute, storage, network, and permission enforcement. In one sentence: unified, but not locked in; centralized governance, but without sacrificing local autonomy. This is especially critical for group-level multi-campus, multi-environment enterprises—headquarters need a global view, while branch centers need to keep running independently during link fluctuations.

For detailed interpretation of the MoM architecture, please read Demystifying the ZVF MoM Architecture

05 / SCENARIO COVERAGE

Four: Will Scenarios Force You to Buy Another Platform?

Virtualization rarely exists in isolation. ITAI requires one-cloud-multiple-chips; Classified Protection (MLPS) and Cryptography Assessment require cryptographic and audit capabilities; branch offices need cloud-edge collaboration; business departments are already asking about GPUs and on-premises models. If the replacement platform can only "run VMs," each subsequent requirement becomes a new project.

Figure 3: Six Scenarios from a Single Virtualization Foundation

Starting from the virtualization foundation, stacking capabilities by business need, rather than replacing platforms for each scenario.

Lightweight AI Cloud — Transforms GPUs from "dedicated machines for dedicated use" into schedulable resource pools, starting from as few as two nodes, supporting training, inference, and on-premises knowledge bases, with emphasis on intranet deployment and permission auditing. For enterprises that have completed virtualization replacement, AI doesn't need to be a separate island.

Cloud-Edge Collaboration — The center needs unified governance; the edge needs local processing. When the link is unstable, edge nodes can still support local business. Multi-site manufacturing and group subsidiaries often need this division of labor more than "buying another small virtualization platform."

Cloud Security and Cryptography Assessment — Determines whether the replacement can pass review in government and financial sectors. Network, data, cryptography, and security operations are consolidated into a unified service catalog; Cryptography Assessment offers both tightly-coupled and loosely-coupled construction approaches, with built-in productized modules to avoid another round of engineering rework after certification. After cloud-enabling cryptographic resource pools, the cost of a single cloud cryptographic machine is approximately 20% of a traditional one.

Note: The cryptographic machine cost ratio is a reference benchmark; actual figures should be calculated based on existing cryptographic equipment and system security level.

06 / TCO & OPERATIONS

Five: Clear Accounting, and the Team Can Sustain It

Whether licensing is predictable, hardware can be retained, and the team can continue working in familiar ways determines whether the replacement reduces costs or merely shifts them elsewhere. ZVF emphasizes hardware-agnostic deployment, modular selection, perpetual licensing with optional subscriptions; ZSphere also supports multi-brand, multi-generation server reuse. These reduce the probability of "replacing hardware just to change platforms."

"Who's cheaper" has no universal answer. The correct unit of comparison is not per-CPU pricing, but the two-to-three-year total cost at the same service level: software, migration, training, backup integration, downtime risk, and subsequent scaling.

07 / WHAT'S NEXT

Replace the List with a Checklist — Replacement Can Move Forward

After passing the five gates, the conclusion is usually not "switch everything plant-wide tomorrow," but a workload inventory: dev/test and general business can be cut first; core production must preserve drills and rollback; ITAI workloads should be pooled separately; AI and edge are layered in by cadence. Bringing this checklist into POC is more useful than bringing an "AI-recommended brand" into the boardroom—the former can be tested and falsified; the latter can only be rewritten by the next question.

The typical landing path is assessment, POC, batch migration, and continuous operation. When conditions are right, some projects can go from assessment to go-live in two weeks, but this should not be treated as a commitment for all production environments.

LLMs can still be used—to organize materials, generate checklists, and remind you not to forget rollback and backup. They should not have voting rights. Voting rights should remain with live-network testing, operations teams, and business continuity requirements.

The endpoint of  virtualization selection is not obtaining an "AI-recommended brand."

It is the enterprise regaining control over costs, risks, and the pace of evolution. What ZStack ZSphere aims to carry is the journey from "moving VMs over" to "keeping the data center running."

For the complete capability list and migration assessment solutions, please contact ZStack regional teams.