VMware to Sangfor Migration: A Step-by-Step Playbook
This playbook is written for VMware administrators with at least three years of experience who are planning a migration to Sangfor HCI. It covers assessment, environment preparation, the migration process, post-migration validation, and common troubleshooting scenarios. If you are looking for a VMware to Sangfor migration path that minimises risk, use this as your operating checklist.
Pre-migration assessment
Start with a complete inventory. Document every VM, host, data store, virtual switch, VLAN, firewall rule, and backup job. Record CPU, memory, and storage consumption with peak values, not averages. Identify dependencies: which VMs must start in sequence? Which applications share a database tier? Which network segments cannot be renumbered?
Sangfor provides an assessment tool that reads VMware vCenter metadata and produces a migration readiness report. Use it to flag incompatible guest operating systems, oversized VMs, and unsupported hardware versions. Combine this with AGR Networks discovery workshops to capture business constraints such as maintenance windows, compliance requirements, and critical change freezes.
Group workloads into migration waves. Wave 1 should be non-critical test and development systems. Wave 2 contains business applications with low dependency complexity. Wave 3 holds the most sensitive production workloads. This staged approach keeps risk low and gives the team confidence before touching revenue-critical systems.
Environment preparation
Sangfor HCI requires a minimum of three nodes for production to maintain quorum and automatic failover. Each node should have dual power supplies, redundant NICs for management, VM traffic, storage replication, and out-of-band management. Verify that your switching fabric supports the required VLANs and jumbo frames for aSAN replication.
| Phase | Task | Owner |
|---|---|---|
| Assessment | Inventory VMs, hosts, storage, and networks | Infrastructure team + AGR |
| Assessment | Map dependencies and migration order | Infrastructure team |
| Preparation | Rack and cable Sangfor HCI nodes | Data centre team |
| Preparation | Configure management, VM, storage, and replication networks | Network team |
| Preparation | Create aSAN storage pool | Virtualisation admin |
| Migration | Install management node and aSV on target hosts | Virtualisation admin |
| Migration | Convert test VMs (online or offline) | Virtualisation admin |
| Migration | Validate performance, HA, and backup | Infrastructure team + AGR |
| Migration | Migrate production workloads in batches | Virtualisation admin |
| Post-migration | Decommission VMware hosts and update documentation | Infrastructure team |
The migration process
1. Install the Sangfor HCI management node
Deploy the management VM or physical appliance according to the sizing guide. Configure IP addressing, DNS, NTP, and SNMP targets. Join the cluster and add the target hypervisor hosts.
2. Configure aSV on target hosts
Install the aSV hypervisor on each Sangfor node. Verify host health, firmware levels, and network connectivity. Create virtual switches that map to your existing VLANs so migrated VMs retain their IP addresses.
3. Set up aSAN storage pool
Combine local disks into a distributed storage pool. Choose the replication factor based on your resilience requirements. Run storage health checks before any VM conversion.
4. Convert VMs with the native migration tool
Sangfor's conversion tool supports both online and offline migration. Online migration copies the disk while the VM runs, then performs a brief synchronisation cutover. Offline migration shuts the VM down, exports the disk, and imports it into aSV. Use online migration for business-hours cutovers and offline migration for large database servers that must remain consistent.
5. Migrate test workloads first
Convert a representative set of test VMs. Validate login, application function, network reachability, and backup. Capture baseline performance metrics so you can compare after production migration.
6. Validate performance and connectivity
Run synthetic load tests against migrated VMs. Check storage latency, network throughput, and CPU readiness. Confirm that each VM can reach required DNS, Active Directory, and application endpoints.
7. Migrate production workloads in batches
Follow the wave plan. Migrate during agreed maintenance windows. Keep VMware snapshots until each batch is validated, so rollback is possible if a workload misbehaves.
8. Decommission VMware hosts
Once all VMs are stable on Sangfor HCI, remove VMs from vCenter, retire the hosts from inventory, and repurpose or dispose of hardware according to your asset lifecycle policy.
| Week | Activities |
|---|---|
| Week 1 | Discovery, assessment, and migration planning |
| Week 2 | Hardware delivery, rack/stack, network configuration |
| Week 3 | Sangfor HCI installation, storage pool setup |
| Week 4 | Pilot migration of test/dev workloads |
| Week 5–6 | Production batch migration (low risk first) |
| Week 7 | Performance validation, HA testing, backup verification |
| Week 8 | Final cutover, documentation, VMware decommission |
Post-migration validation
Validation is not optional. Verify the following before declaring the migration complete:
- Performance benchmarks meet or exceed the VMware baseline.
- High availability failover works by simulating a host failure.
- Backup jobs complete successfully and restore tests pass.
- Disaster recovery replication is healthy.
- Security policies (NGFW, micro-segmentation) are enforced.
- Runbooks and network diagrams are updated.
Common issues and troubleshooting
Network configuration
The most common issue is VLAN mismatch. Double-check that virtual switch port groups on Sangfor map exactly to VMware distributed port groups. Verify trunking on physical switches.
Storage performance
If latency is higher than expected, check replication factor, disk health, and whether jumbo frames are enabled end-to-end. Ensure SSD cache tiers are sized correctly.
VM compatibility
Older operating systems or unusual virtual hardware versions may need tool updates or minor reconfiguration. Convert these during pilot waves, not production cutover.
Script migration
Most PowerCLI scripts map to Sangfor CLI with a prefix change. Validate syntax in a lab environment before running production automation.
Get expert help
AGR Networks runs VMware-to-Sangfor migrations across Singapore and Asia-Pacific. Book a free migration assessment and we will produce a tailored migration plan, risk register, and TCO projection for your environment.