Migration of a distributed switch (vDS) to a new vCenter (PowerCLI edition)

### UPDATE: I received some posts / comments that my approaced way does NOT work when using LACP. I haven’t had the time to get deeper into that topic, but please be aware of that fact.

Reviewing Google analytics for my old blog on vxpertise.net showed that my article a few years ago is still kind of famous.

It explains how the distributed switch import/export feature can be used to migrate existing ESXi to a new vCenter. I extended the information explained in this blog post with a few lines of PowerCLI code that makes the whole process a lot of easier/faster/less error-prone.


This requirements is raising up more and more in environments of people I deal with. Especially the awesome vCenter Server Appliance (vCSA) convinces people to create a new vCenter from scratch.

How can I deal with it when I have a distributed switch in place? No big deal as long as you keep the correct order in mind:

  1. Backup the vDS on the old vCenter

  2. Disconnect and remove the ESXi hosts from the old vCenter

  3. Connect the ESXi to the new vCenter

  4. Restore the vDS on the new vCenter (preserve the original distributed switch and port group identifiers)

Those steps will create NO network interruption during your migration!

The manual steps are provided in the above mentioned article and are still valid. But how can we accelerate this process (or get it done without using the webclient ;-) ).



  1. The new vCenter is installed and ready
  2. A datacenter object has been created

So let’s check the script that do the relevant tasks to add the ESXi hosts at the new vCenter

Change the variables on the top and add the existing ESXi in your environment that you want to migrate.

$datacenter = 'LE01'
$esxList = @('esx01.lenzker.local', 'esx02.lenzker.local', 'esx03.lenzker.local')
$user = 'root'
$password = 'VMare1!'
$vDSLocation = 'C:\Users\Administrator\Desktop\vds_backup.zip'
foreach ($esx in $esxList){
    Add-VMHost -Location $datacenter -Name $esx -Force:$true -User $user -Password $password
New-VDSwitch -BackupPath $vDSLocation -Location (Get-Datacenter $datacenter) -KeepIdentifiers:$true

(The password has been changed is the VMware HOL / Teaching default password ;-) )

After that your ESXi should be connected to the vCenter and synced with the correct distributed switch control-plane (on the vCenter level). You can find the PowerCLI file here

7 thoughts on “Migration of a distributed switch (vDS) to a new vCenter (PowerCLI edition)

  • 1. June 2017 at 17:02

    Hello I am pretty sure this is not a supported method . However , can you comment on the strike rate . I am stuck on IBM FLEX and LACP with supported methods

    • 1. June 2017 at 18:55

      This is indeed an unsupported method. I will add a note to the blog post.

      It never really worked out with an IBM flex so far. Only way is to make the step back to a vSphere standard switch and than migrate to a new vDS.

      I know that’s a pain in the a***;(

      • 2. June 2017 at 7:32

        Thank you for the feedback , the VSS route is my current plan . For the sake of the community I will update on progress in a few weeks , as test reveal that if you have Port Channels ( no LACP ) upstream , and IP hash on vSphere , even the creation of the VSS is disruptive .

  • Pingback: Exporting/Importing vDS Configuration in vSphere 6 – Virtual Reality

  • 18. July 2018 at 15:24

    You need to connect our hosts to the new vCenter first, before you restore the vDS configuration for this to work.

    We tried to restore the vDS config first, but the vDS did not see the newly added hosts.

    • 25. July 2018 at 12:56

      Yeah I have seen multiple & different behaviours across multiple environments. It was always possible to keep it up, running and in sync again – but still it is not my preferred method to do a migration anymore (afaik it is not supported as well).

  • 18. July 2018 at 16:01

    we did needed to reconnect every VM to the right vDS portgroup again. (no downtime)


Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.