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.

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.

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.

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.

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.

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.

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

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.

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??

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?