There is a possibility that VMware will discontinue the Windows vCenter application. You can see it with every new vCenter Release that there is a push towards using the VCSA to manage the vSphere environment. Even now, some newer features in vSphere can't be used from the traditional Windows-based client.
There are several benefits to using VCSA, but there are also some limits.
Here are the benefits of using the VCSA:
There is no Windows OS license for vCenter Server
No patching or upgrading of Windows OS is required
There is no need to maintain third-party tools running on your vCenter Server
It's a fast deployment—no Windows OS or vCenter application to install
It's possibly the vCenter of the future
Here are the current limits when using the VCSA:
Oracle is the only supported external database
The VCSA is Software Und System Entwicklung (SUSE) distribution and there are no OS-level patches from VMware
You would need a certain amount of Linux experience when using the appliance
No Update Manager
Problems occur when running local scripts (alarms)
No integration of Powershell into Alarm execution
No integration of already existing Windows system monitoring tools
There are no automated tools to help with this migration from Windows vCenter to the appliance. You need to deploy a new appliance and follow the procedure mentioned next to move the host from your original Windows version to the appliance.
Here are a few things to complete before you begin:
Document the current resource pool configurations
Record all DRS rules and groups (you will create the rules after the new vCenter connects to the VMs)
Document and verify the port configurations of the physical network
Have Update Manager on the Windows version of vCenter in order to upgrade the host to 5.5 after the migration
After you feel that you have the information you need to make sure you understand your environment, you can schedule some downtime and begin the following migration process:
Install, configure, and verify the new production VCSA. Make you can login and then recreate your resource pools, folder structure, and the permissions to match the current environment.
If using vSphere Replication, disable it along with HA on the old vCenter.
Halt DRS by switching it to manual mode. Your resource pools will be removed if you disable DRS.
It is a good idea to export from the old environment and then import the vSphere Distributed Switches (vNDS). This makes the rebuilding process easier, if needed. If you are going from version vSphere 5.1 to VCSA 5.5, keep the current version of the distributed switch. You will upgrade this later after you import the host, which is still at 5.1.
Then, remove all additional components from vCenter such as vRealize and other third-party consoles from the old vCenter.
Move the VMs to standard virtual switches by using the secondary links for the standard vSwitch. When you add a host to a virtual distributed switch, there you will specify the uplink NIC for hosts and vCenter will assign that NIC to the first uplink slot.
Remove the ESXi hosts from the old vDS.
Now, disconnect (do not remove), one at a time, each ESXi host from your Windows-based vCenter and add them to the new VCSA. Try to keep the same resource pools using the documentation that was created before the process.
Verify that the resource pools are correct and then create DRS & HA rules from the information you gathered before the migration.
Add the new imported ESXi hosts to the configured VCSA vDS. Remove the standard vSwitch along with re-adding the NIC to the secondary uplink.
Shut down the old vCenter.
Re-enable HA and put DRS in fully automated mode on the new vCenter.
Move any DNS names related to services.
Use Update Manager to update your hosts to 5.5.
Migrate your virtual distributed switch to 5.5.
Check and double check along the way to make sure each step is completed to your satisfaction. As with most projects, take the time to verify and document what you have. Put together a plan and always have a procedure to go back to, if needed.