Migrating vCenter from 2012 to 2012 R2 with 5.5 Update 2

I was under the impression that migrating vCenter to a new host was a difficult and risky process. That is, until I spoke with some nice folks at VMworld who said it was no big deal and only required moving the SQL database. Excited to get rid of 2012, I took on the task of migrating our vCenter on to a new 2012 R2 VM. While I discovered it was more than a simple SQL migration, it was actually pretty easy.

 1. Backup your old vCenter files

  • Make a copy of your “C:\ProgramData\VMware\VMware Virtual Center\SSL” folder.

The installer does a good job of reminding you if you forget.

SSL Files Missing

  • Make a copy of your “C:\ProgramData\VMware\VMware Update Manager\Data\hostupdate” folder.

Not always necessary, but I had a few offline bundles that I uploaded to VUM and ran into some “unknown errors” scanning hosts after the upgrade because of this.

  • SSO @vsphere.local accounts

Since I only had six @vsphere.local service accounts and all the passwords were documented, I just re-created these after the migration. Follow the steps documented in KB2057353 if you would like to migrate your SSO accounts.

  • The VCDB SQL database

VUM and vCenter share the same database in our environment. If you’re unsure how to perform a full SQL backup then check this MSDN article or ask a fellow admin.

  • Shut down the old vCenter

We retained the same host name and IP address from the old to the new server so the old one must be powered off. Hang on to it until you’re confident you don’t need it anymore.

 2. Prepare the new host

Build out the new OS and join the VM to your domain. Install SQL 2012/2014 and prepare your instance.

Restore the VCDB database

Simple procedure documented here.


 Create the DSN’s

We’ll need to create two DSN’s. A 64-bit DSN for vCenter, and a 32-bit DSN for VUM.

  • Open control panel and type ODBC in the search bar. Click on “Set up ODBC data sources (64-bit).”
  • Open the System DSN tab and click Add.

System DSN

  • Select SQL Server Native Client 11.0 (this version is the same for SQL Server 2012 and 2014).
  • Our instance name is vCenter. The “.” in the server field just means the instance is local.

Create new Data Source

  • Enter the credentials for your vpxuser account. This was documented when you stood up the original DB, right? If not, launch SQL Server Management Studio and change it. Make sure the password does not contain special characters!
  • Accept the default values.


  • Click Finish.


  • Test your data source and click ok!


  • Now we have to create a 32 bit DSN for VUM. No big deal. Repeat the above steps but this time click “Set up ODBC data sources (32-bit).”

Copy the vCenter Certs

  • Create a “C:\ProgramData\VMware\VMware VirtualCenter\SSL” Folder and copy the certs you backed up here…

Unfortunately these are not the certs for the web client, but rather used for communication with the hosts.

Install vCenter Server

Server 2012 R2 is supported in vCenter 5.5 update 1, but I installed the latest, update 2.

  • Launch the vCenter Installer and perform a simple install. In most cases the defaults are fine.
  • When you get to the Database Upgrade Warning select Upgrade existing vCenter Server database.


  • If you receive the following error during the install, you will need to make sure your vpxuser SQL account does not contain special/non-alphanumeric characters.


  • Complete the vCenter simple install.

 Copy the VUM hostupdate files

This is only necessary if you have offline bundles that you uploaded, or plan to change your download sources.

  • Simply copy the files you backed up to “C:\ProgramData\VMware\VMware Update Manager\Data\hostupdate\”

Recreate SSO accounts

Since I decided not to back up my SSO files, I recreated my @vsphere.local accounts as well as configuring our AD accounts.

That’s it! You’ve successfully migrated your vCenter!

Matt Bradford


    • Hi Daniel,

      Right after building the VM. We use customization specs so I often forget to include joining to the domain in my steps. Thanks for the question! I’ll update the article.


  1. Perfect, I was wondering because once it is joined to the domain it would break the domain trust relationship between the old server and the domain. I see it was done after shutting down the old server. Thank you for the clarification, the step-through guide here and for taking the time to post it. I will be using this shortly.


  2. Nice manual ..
    Just one question do you have any idea what happens when you are migrating at the same time to a new domain and IP address.
    Can you in this case leave the old vcenter on and connect the host again in the new vcenter and accept the message that this host is being managed
    by an other vcenter

    • Hi Nico,

      Thank you for your comment. That’s a very interesting question, and something I have not tried myself, so please don’t take my response as an authoritative one.

      I can see why it would make sense to change the domain and IP now, but I would personally do the vCenter upgrade first and then proceed with the IP and domain change. Otherwise I think there will be too many changes making it difficult to identify the cause of any issues.

      To answer your questions…
      I would assume by accepting the “host is being managed by another vCenter” message that the new vCenter server would take over control and the old vCenter would show the ESXi hosts as disconnected. If it were me, however, I would disconnect the hosts from the old vCenter and re-connect them on the new one, just to be overly cautious. I can test this in my lab this evening and let you know.

      You will have to reconfigure plugins such as VUM and vCOPS with the new IP/FQDN (unless you’re using localhost). Chris Wahl has a nice PowerCLI script to identify the plugins. http://wahlnetwork.com/2014/10/06/applying-new-ip-addresses-vcenter-esxi-hosts-plugins/

      Because you’re on a new domain, you’ll have to re-generate your SSL certs too. I’d also recommend reading Frank Buechsel’s blog post on re-naming a vCenter host as the FQDN of yours will change. He picks up a lot of gotya’s here and shows how to fix them.

      I hope this information helps. I’ll let you know this evening about connecting the ESXi hosts to a new management IP.


      • Hi thank you for your fast response.
        let me know the results i will try to do a POC migration this thursday.
        Gr nico

        • Hi Nico,

          You are absolutely correct! Accepting the Duplicate Management warning will connect the host on the new vCenter and disconnect it from the old.

          To test, I cloned my vCenter and gave the new clone a new IP and name, the vCenter Unique ID is the same for both hosts.

          vCenter 1 Connected, vCenter 2 Disconnected

          I connected the host on vCenter 2.

          Connect ESXi Host on vCenter 2

          I ran through the Add Host Wizard and accepted the Duplicate Management Dialog that you described.

          Acceot Duplicate Management Dialog

          After a few seconds the host was connected to vCenter 2 and disconnected from vCenter 1 as you would expect.

          Host connected to vCenter 2

          After migrating the ESXi host to the new vCenter server I was able to view historical performance data and manage the host normally. It worked great!

          I hope this helps and good luck with your migration!

  3. If you have an external SQL server do you simply do the same process but omit the SQL restore activities? Is there an option to choose an existing DB and will you not get prompted to update the SQL database (assuming there is no upgrade in the vCentre versions)?

    Also could we follow the same process when migrating from version 5.0 to 5.5 at the same time as migrating to a new host??

    • Exactly. When you configure the new DSN’s just point them to your external DB.

      vCenter 5.0 to 5.5 is a pretty big jump. I’d recommend engaging your account team or VMware support.

      • Perhaps its better to do a two step process – migrate to a new host first then do an in place upgrade?
        Or alternatively an in place upgrade then migrate to different host (assuming the host is as supported version).
        Do you see any issues with either of these approaches?

        • FYI, I ended up doing the 2 step process. That being do an in place upgrade from 5.0 to 5.5. Then following your process to migrate to a new host (2008R2 SP1 to 2012 R2). All went well.

  4. Have you installed vCenter using SQL 2014 as the backend? In prepping for an upgrade I haven’t been able to find the 2014 sql native client required by vCenter for sql 2008 and 2012.

Leave a Reply to Nico Teuben Cancel reply

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