What a Bank IT Leader Learned in 200 Days Replacing VMware

1. Are Domestic Virtualization Products Reliable?

The author surveyed peers: a city‑bank successfully ran 80% of its systems on a domestic platform, cutting costs by 40%, while another securities firm struggled with driver compatibility, spending two weeks fixing a single business system.

Field tests revealed that domestic solutions can match core features—heterogeneous cluster management, cross‑cluster migration, snapshot backup, high‑availability—but they fall short in resource overcommit. VMware allowed CPU overcommit ratios of 1:8 or higher; domestic products typically cap at 1:2–1:3, forcing additional hardware investment.

Performance proved inconsistent: on a domestic platform Oracle IOPS were 15% higher than on VMware, yet SQL Server throughput dropped 20%. Re‑testing the same hardware produced divergent results without a satisfactory explanation from the vendor.

Memory over‑subscription is another pain point. Many domestic vendors claim memory oversubscription but refuse it in planning, and most lack true oversubscription capabilities, leading to full memory allocation that jeopardizes Java‑heavy workloads.

Backup and recovery also lag behind. Snapshot‑based backup consumes more resources and restores slower than VMware’s ecosystem. Integration bugs with third‑party storage arrays caused frequent backup failures.

2. How Many Pitfalls Lie on the Compliance (Xinchuang) Road?

The bank’s head office mandated that core systems achieve a 50% Xinchuang (domestic‑software) ratio, meaning the virtualization swap had to coincide with OS, database, and middleware replacement.

Key challenges included:

Instruction‑set compatibility: Moving to ARM‑based domestic servers required source code recompilation; some legacy binaries were unavailable, leading to a split deployment of x86 and ARM clusters.

Full‑stack adaptation complexity: One core application involved 18 hardware/software components, 56 interface protocols, and over 200 configuration items; any single failure could stall the entire migration.

Security compliance: Under the Tier‑2 Level‑3 security standard, 127 configuration items must be satisfied, yet many domestic platforms lack mature audit and access‑control features.

3. Will New Products Remain Stable Over Time?

Short‑term tests look promising, but long‑term stability remains uncertain. Some peers report steady operation, while others experienced unexplained outages.

Support quality varies: VMware offers a global support network, whereas domestic vendors often rely on agents or outsourced engineers, leading to inconsistent technical assistance.

4. Migration Strategy: Gradual or All‑at‑Once?

The team debated a full‑stack replacement versus a phased approach. Risks of a full swap include massive coordination and potential business interruption; a layered migration reduces technical difficulty but may leave hidden compatibility issues.

After extensive deliberation, they adopted a “step‑by‑step” plan:

New systems launch with a full Xinchuang stack.

Existing systems are prioritized by business criticality and migration difficulty, with staged replacement phases.

Non‑core systems serve as pilot projects; detailed rollback procedures are prepared for each phase.

Compatibility testing is performed early, uncovering numerous issues—e.g., a migration window expected to take 4 hours expanded to 12 hours due to storage‑compatibility bugs.

Vendor cooperation is evaluated through technical support performance during test migrations.

Team skills are upgraded via targeted training and hands‑on evaluations.

5. Final Thoughts

The replacement journey exposed no perfect product; success depends on choosing a solution that fits the organization’s specific workload and risk tolerance. Maintaining an open mindset, thorough preparation, and balanced risk assessment are essential for navigating large‑scale infrastructure transformation.