vSpehere upgrade with new vCenter server build

[mahesh14584]

Hi There,

We are running on vSpehre 5.5 with 20 ESXi hosts and one Windows vCenter server, and planning to upgrade the infrastructure to vSphere 6.5 U1.

We would like to follow green field approach for upgrading the platform. That means instead upgrading the existing vCenter server, deploy the new vCenter server appliance (without native HA), install, configure then migrate the ESXi hosts to new vCenter server, finally decommission the Windows vCenter server.

Could you please help me with high level steps that I need to follow for this?

thanks

Mahi

[daphnissov]

It looks like you posted the same question earlier here.

The process of performing a greenfield deployment of vSphere 6.5 and migrating resources could have several possible steps and many things to take into consideration. Overall, the high-level process is something like:

1. Determine an architecture for the new vCenter environment.
2. Deploy the vCenter environment.
3. Configure vCenter basics.
4. Perform host readiness preparation at the source vCenter.
5. Migrate any logical vCenter objects to new vCenter.
6. Disconnect hosts at source, join to destination.
7. Perform inventory reconfigurations as necessary.

Deploying the vCenter is straightforward because it is a net new deployment, but you'll need to determine the architecture you want up front planning for your future scaling needs. Migrating the hosts and resources come after the fact, but some caveats to keep in mind when doing so.

• If using vDS at source you will need to migrate to vSS first.
• If using NSX or vSAN, other specific caveats apply.
• If using custom roles, custom permissions on objects, vSphere folders, resource pools, and other vCenter logical constructs, they will need to be backed up and migrated manually.

You also need to assess any and all external solutions including plug-ins and other applications that have a dependency on vCenter for their communication path. This includes things like monitoring applications, security tracking/audit discovery applications, backup and replication applications, etc. Because these resources get moved to a totally new vCenter, they get new IDs assigned to the objects. The implications this has on the aforementioned applications is that it is seen as a new environment. In the case of backup, your application will see them as new VMs and begin the full backup process all over again. Monitoring won't align with previous data, and there may be a new audit trail associated with "new" VMs.

So there are lots of things to think about and plan before you embark on this. All of this said, there are great benefits of choosing this path over an in-place upgrade.

1. Risk of failure is much lower due to complexities in earlier versions and permutations of settings.
2. Opportunity to correct and optimize architecture and settings rather than porting them over.
3. Greater stability and reliability because of elimination of legacy artifacts from upgrade process.

After doings lots of these for other customers as well as in-place upgrades, I do try and recommend these greenfield "lift-and-shift" approaches, especially when it comes to major vSphere version changes (for example moving from 5.x to 6.x) because of the three points I mentioned above. There is a little more work and planning that goes into it, but the outcome is always a better experience and a more solid environment at the end of the day as well as years down the line.