VMware exit to a Swiss cloud: checklist

Without this list, every cutover is theatre. You build it once, it serves every wave, and it is what decides the schedule.

• Clusters, hosts and VM count per cluster
• OS and version of every VM, flagging support end-dates already passed
• Active Directory dependencies: controllers, DNS, GPOs
• VLANs and port-groups, with the filtering rules that go with them
• Current backup chain and where the copies actually land
• RPO and RTO the business expects, not the ones written in an old contract
• Windows Server and SQL licences: licensing mode, and what is transferable
• Site-to-site links, VPNs and exposed public IP addresses
• VMs with no identified business owner: this is the line that delays projects

Put your Broadcom renewal date on a calendar and count back. Order of magnitude for a 40 to 120 VM estate: T-16 weeks the inventory and the choice of waves; T-12 the 10 to 20 VM pilot, network, backup, one Windows app and one Linux; T-8 the wave imports, starting with what tolerates thirty minutes of downtime; T-4 the cutover of the last workloads, window by window; T-0 vSphere shutdown and contract end. Under eight weeks, negotiate a short Broadcom extension rather than hold the date: three months of licence cost less than a failed cutover on a Sunday night. And decide early who executes (section 9): that is the constraint that moves the schedule most.

The pilot is not a demo: it is the draft of the runbook your waves will follow. So it has to contain each difficulty you will meet a hundred times, once, and nothing more. A Hidora engineer frames it with you.

• Ten to twenty VMs: enough to surface the problems, few enough to start over
• One Windows application and one Linux, to exercise both licensing chains
• A workload that tolerates thirty minutes of announced downtime
• At least one Active Directory dependency, or the site-to-site link goes untested
• A volume to restore, to validate the restore and not just the backup
• A business owner reachable during the window
• Excluded from the pilot: the most critical workload, and any VM whose topology nobody knows

Hikube imports VMDK, QCOW2 and ISO. Lift-and-shift keeps the OS: no mandatory application rewrite. Windows Server re-licenses on usage. Instance detail: cloud instances.

• Two VM lists: thirty minutes of downtime tolerated, or hot replication required
• vCPUs counted per Windows VM before the pilot: the licence follows usage
• VMware guest tools removed, the new platform’s agents installed
• Boot verified after import: network, disks mounted, application services
• Do not start with Kubernetes unless the application is already containerised

Map prod, DMZ, backup and admin onto Hikube VPC subnets. Complex NSX micro-segmentation does not always map 1:1, plan a workshop rather than an automatic translation. Detail: the VPC private network.

• VLAN → subnet mapping table, one line per network
• Addressing plan settled before the first import, not during
• Filtering rules rewritten and reviewed, including the ones nobody claims
• VPN or site-to-site link established and tested against the existing Active Directory
• DNS resolution validated in both directions
• Public IPs and external DNS records listed, TTL lowered before the window

Do not “turn on backup” on cutover day. Backup in the Swiss tenant replaces the Veeam or on-prem brick once the VMs are imported, and the copies stay in Switzerland. Detail: managed backup.

• Backup running on the imported VMs before they go live
• The RPO and RTO from section 1 carried into the backup policy
• One full restore executed in the pilot, and timed
• Copy location verified: they stay in Switzerland
• The old backup chain kept until the last wave is finished

A wave groups VMs that share a window and an owner, and starts with what tolerates announced downtime. At the end of each window the points below are ticked or they are not: if one is missing, it is a rollback, not an item to handle on Monday.

• Window announced, business owner and engineer present
• The VM boots and all its services respond
• A test application write is visible in the database after the switch
• Response times within the envelope measured before migration, not “looks fine”
• Backup of the migrated VM taken and verified
• Monitoring sees the VM and its alerts are live
• No user ticket related to the switch in the two hours that follow

A rollback documented after the fact is not one. It exists only if the source stays bootable and the decision time is set before the window opens, while nobody is yet committed.

• Source VM left powered off but intact on vSphere, never deleted during the wave
• Decision deadline set before the window opens
• One named person calls the rollback: not a consensus at three in the morning
• DNS and IP switch reversible, TTL already lowered
• Data written during the window: identified, then replayed or knowingly lost
• vSphere kept licensed until the last wave is validated

A Hidora engineer frames the inventory, the network workshop and the pilot: that is the starting point in every case, and the deliverable is the pilot’s runbook. For the factory, three setups. Your team runs it with that runbook, if it has the hands. Or Hidora runs it as project work under a SOW, billed by time spent or milestones, on top of PAYG. Or a partner integrator owns the project and keeps the customer relationship. A two or three person team will not carry a hundred VMs on top of its day job: decide at framing, not on the last weekend.

Two questions to settle before signing, not after. Support: 24×7 monitoring and on-call of the infrastructure on the Hidora side, a support desk on business days 08:00–18:00 CET in French and English, maximum response times per priority (P1 critical, 4 h). Your OS and applications stay under your own monitoring, exactly as under vSphere; the exact split is on the support scope. Reversibility: the contract governs the return of your data at the end of the relationship, procedure, retention period and any fees are set there, and the contract is what binds (the general terms). Technically nothing is proprietary: volumes export as disk images and object storage is S3-compatible. Apply this same checklist to your next provider, including to us.