Migrate VMWare from old servers to new servers

[bfry24]

Being new to VMWare, I am looking for documentation or anything that will assist in moving 2 ESXi's and 1 vCenter from two older server to two brand new ones.

Any potential got ya's, etc.

Any help would be appreciated.

[scott28tt]

This should help: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-vcenter-upgrade/GUID-7AFB6672-0B0B-4902-B254-E...

[bfry24]

Thank you for the reply, but that discusses upgrading.  I am looking for something regarding moving the whole system from one set of servers to a new set of servers.

[scott28tt]

Current version of vCenter? And of ESXi?

Intended version of vCenter? And of ESXi?

Storage of existing VMs?

[DCasota]

Hi,

at the time a system with two ESXi hosts and 1 vCenter has been introduced, its purpose usually was for a group of applications on virtual machines. And, such systems often have been introduced and maintained as single-shot projects.

Applications today evolved to SaaS subscriptions, were relaunched as containers, refactorized alongside to the supply chain, are made available at scale on hyperscalers, etc. 

From a digitization perspective, your local VMware partner acts as business sparring partner and can help you to get the right things right.

Many of your applications are on AWS, Azure, GCE ? Seize opportunities, monitor risks. Get applications' context, facts&figures, planning, support, operations. Identify the actual and future security controls and multi-cloud requirements of your business. 

VMware addresses this by a unified approach to Multi-Cloud Architecture | VMware. In addition, have a look to ISO/IEC 27001. Defense in depth for cross-cloud services is a companies' bread&butter and the greatest possible deterrent of "do-it-yourself". That's why many companies already migrated their VMware IT infrastructure to a VMware Skyline partner.

Scott's advice is the gold of VMware SME partners. A migration to the latest vSphere version always is preliminary work for automation.

You inherited the production environment and are new to VMware - hence, imho forget the jumpstart into VMware vSphere docs.
In the age of AI, better ask business questions and discuss reality impact goals with your VMware partner.

Hope this helps. -Daniel

[IsuruSameera]

From my understanding the best approach is, install ESXi on the two new servers, add them to the existing vCenter, and then migrate the VMs including vCenter server to new ESXi hosts and then decommission old ESXi hosts from the environment.

This is a high level suggestion and if you need more info for a better approach we might require some additional details about your environment. Like existing server specs, new server specs, ESXi and vCenter versions, Shared storage availability etc.

please thumbs up if this helps.

[bfry24]

The existing servers are Dell PowerEdge R710's with 12 CPU's x Intel Xeon CPU E5645 @2.40GHz, 144GB RAM with 1 HDD (shows 271.25GB) that is configured as a Datastore.

The main Datastores are on a Synology NAS.

The new servers are Dell PowerEdge R750's with 16 CPU's x Intel Xeon Gold CPU 6326 2.9GHz, 512GB RAM with 2 BOSS-S2 Controller card + with 2 M.2 240GB Drives and an additional 4 480GB SSD SATA drives, Windows Server 2022 Datacenter, VMWare ESi 8.0 Embedded.

Our current version of ESXi is 6.7.0 Update 3 and vCenter is on verstion 7.0.3.01600

[DCasota]

Hi,

Here some thoughts.

1) the new system must be up and running. It already has been sized. Hence, facility/power/cabling, hardware, esxi configuration, network and storage drivers, network and storage configuration preliminary work must have been successfully completed. From the new esxi hosts, you can access each of the Synology datastores, you can backup&restore test virtual machines, you can monitor the hosts, determine the performance characteristics, health, etc.

2) The old and the new system with two ESXi hosts already has been sized for business continuity topics. Hence, detaching/attaching one by one from the old vCenter 7 to the new vCenter 8 can be part of a migration plan.

3) With shared storage (NFS/iSCSI, e.g. see How do I install Synology NFS Plug-in for VMware VAAI on an ESXi host? - Synology Knowledge Center), you can move virtual machines to the new hosts, and/or unregister, re-register virtual machines and templates.

4) When should you go through the Update Sequence for VMware vSphere 8.0 and Compatible VMware Products (89745) or make use of tools e.g. the VMware Solution Designer | VMware Flings?
Implicitly, supporting the existing Life Cycle model implementation is the use case. It may include some optimization aspects e.g. inplace migration of the guest os and it is a well-known migration path including going through vendor application migration docs' e.g. Overview of Windows Server upgrades | Microsoft Learn .
If you don't need to maintain existing virtual machines from the old esxi hosts and the datastores' data can be attached to newly created virtual machines and/or containers, it is still the same Life Cycle model implementation however without migration sub-step.

In 1)-4), questions will certainly come up. Just ask.

The thoughts above are for an onprem setup, without vSphere+ and automation aspects.

[markey165]

@bfry24 - we've recently done something similar, and this is fairly straightforward.

1. Build your new environment as you like it. Use the 60 day eval licenses. Get everything just right. Test it. Document it, Tear it down, build it again, until its ready. Obviously on your final build you want as close as possible to the full 60 days to give you time to migrate your workloads
2. Use either Cross vCenter vMotion (same vCenter SSO domain) or Advanced Cross vCenter vMotion (different vCenter SSO domains) to "pull" the VMs across from the old platform to the new platform. you will obviously need the same Port Groups for non disruptive vMotions. Make sure you test connectivity before you go live.
3. Upgrade your license keys in the Customer Portal from 6.7 to 7.0 (or 8.0) then apply your new license keys to your new environment.

Note: if you have a TAM, let them know you're planning an upgrade so they can be on hand to assist with any issues around licensing or similar.

We wanted a clean start, and went from 6.7 to 7.0 using the steps above and found it very straightforward. We migrated 450 VMs using Advanced Cross vCenter vMotion with zero downtime. HTH Good Luck

[DCasota]

Hi @markey165 ,

Your straightforward ~migrate-your-workloads recipe looks interesting with respect to ML attempts. I haven't done a MLflow model description before, and it may be completely useless, but here a high-level description of a MLflow model adopted from learning resources found.

Define the problem: Transform 'migrate VMware from old servers to new servers' to a MLflow model subscription

1. Goal resources: Create the necessary vSphere resources for the solution. 
2. Model development: Explore and process the migration 6.7 to 7.0 (or 8.0) to train and evaluate a ~migrate-your-workloads MLflow model. Choose a license baseline and parameter values.
   Test it. Log it, Tear it down, build it again, until its ready.
   must-have feature(s): Cross vCenter vMotion, Advanced Cross vCenter vMotion.
   nice-to-have feature: license key migration automation 
3. Continuous integration: Package and register the MLflow model (e.g. Github Actions).
4. Model deployment: Deploy the MLflow model to an endpoint to generate predictions.
   Let TAMs know about your plan of a custom MLflow model.
5. Continuous deployment: Test the MLflow model and promote to production environment
6. Monitoring: Monitor the MLflow model and endpoint performance