Recently, I “fortunate” enough to experience some issues with a vCenter Server or VCS, the version of vCenter that you install on Windows. It had been upgraded 5.1->5.5->6.0->6.0U1 and apparently something broke along the way. I much prefer the VCSA, so this wasn’t the end of the world, but the issues we encountered forced our hand as to timing. Therefore, some of the migration steps were a bit ad hoc. This was also a small installation (<25 hosts) and a one-time event, so the question Is It Worth The Time? to automate the migration was judged to be a no. I still think that was the right evaluation, but we did find one thing that added some time to the effort: migrating a Distributed vSwitch (DVS).

The process we followed at first was:

1. Export the DVS from the VCS
2. Import the DVS to the VCSA with the Preserve box checked
3. Disconnect/Remove From Inventory a host from the VCS
4. Add A Host to the VCSA
5. Attach the host to the DVS
6. Repeat steps 3-5 for all hosts

Initially this process seemed to work. All the VMs remained on the network throughout the migration (maybe 1-2 dropped ICMP packets in step 5, no application issues). Unfortunately, the VM vNIC distributed port group assignment could not be changed properly in the web client. Only some ports would show and the Browse Networks window would be empty. Looking at the DVS, you could see the attached hosts, but when viewing the DVS Uplinks, there were no hosts attached. Ooops.

At this point, we had moved things around too much to follow the correct order as suggested by Brian Graf:

1. Export the DVS from the VCS
2. Disconnect/Remove From Inventory a host from the VCS
3. Add A Host to the VCSA
4. Repeat steps 2-4 for all hosts
5. Import the DVS to the VCSA without the Preserve box checked

I tried steps 2-5 but, though the hosts were attached to the DVS they did not attach to the Uplinks. Here is the order of steps I followed instead:

1. Disconnect/Remove From Inventory all affected host from the VCSA
2. Delete the DVS from the VCSA
3. Add A Host to the VCSA for all hosts
4. Import the DVS to the VCSA without the Preserve box checked
5. Rename the DVS (not necessary, but the Source/Destination in the next step are the same if you don’t, and that is a tad confusing)
6. Use the Add a Host to this DVS wizard to add each host to the DVS (I used web and thick client, both work and neither is particular faster than the other)
   1. Check the top three check boxes – add the host, migrate vmkernels, and migrate vm networking.
   2. Map the vmkernels and vmnics to the correct distributed portgroups. I found the old client would show the old name in Edit Settings, but the Web client would not. Both wizards show a blank space in the wizard, so it helps to have two clients running during this.
7. The host will have alarms afterward as the read-only heritage DVS now has no uplinks.
8. A few minutes after the host is migrated, the Settings/Networking section will show the old, un-renamed DVS go away. You can hurry this up by deleting it manually. This will remove the uplink alarms from the host.

I was a bit under the gun doing this so I was not able to capture screenshots or more clear directions as I went. I may have some of the labels a little off, sorry.

This was not fun, but it is done. If you can plan the migration, I suggest working on some PowerCLI to handle it, as Brian suggested. I could not imagine having to do all those manual steps with 50 hosts or 500 VMs, much less anything larger! But, ff you do have to make an emergency vCenter migration, I hope this helps!