Integrating existing SDDC management components and aligning their architecture to the VMware Validated Designs standard could be required if retaining VM metadata is a requirement or if the environment contains many third-party or custom integrations.
This migration option requires significant planning and a well-defined starting point to ensure the migration plan will be successful. Certain software configuration options cannot be re-configured and therefore might require a new installation. Using this process does not require a significant decommissioning process because it reuses the existing infrastructure.
Document the software version, build number and architecture of the existing management components. Evaluate the following requirements about each component.
Is the current version of the management component compatible with the software stack that is used in this VMware Validated Design?
Can you upgrade the current version of the management component directly, or is a multi-step upgrade process required?
Can architectural changes be made during the upgrade process?
What inter-dependencies does this version of the software have with other parts of the management stack?
Duration and Maintenance Windows
After you have the initial information about the management components in the environment and establish a high-level migration plan, prepare a test environment to simulate the existing source deployment. Use it to establish a baseline for migration time lines, ensure that the order of operations is correct and identify gaps in the initial migration plan.
After a baseline has been established through successfully migrating the test environment, you can start detailed planning of the exact maintenance windows for the production migration. According to the size of the environment, the amount of data the management components hold and the size of available maintenance windows, you might define a multi-stage process to complete the migration end-to-end.
Perform the migration on a test environment that is as similar to the production environment as possible.
Consider the following best practices to avoid common mistakes during migration:
Document every change that you must make including a rollback plan for the change.
Avoid trying to change too many management components within the same change window.
If a management component change can support a hybrid state, allocate the modified component time before moving on to the next.
Having VM metadata is beneficial to understand how the environment has acted in the past, but it also brings a lot of potentially outdated and unused information. This obsolete information can impact management component performance because the management components are not starting on a fresh installation.
Under certain conditions, you might not be able to reconfigure some management components and you must reinstall them. In this case, the metadata associated with such a component is lost and a complete historical view might not be possible without some gaps.
Backup and Rollback
Before any work can commence, implement a backup and restore mechanism for all management components and workload VMs. Test the restore capabilities of these backups to ensure data integrity.
Using VM snapshots during the migration provides multiple rollback points. Ensure that old snapshots are cleaned up both before and after the migration procedure.
Prepare a plan about the order of the operations and how to roll back to a previous state. You avoid the case where several products have been changed, but only one has been rolled back because of an error. Such a situation might make break the integrity of the environment if the rollback is related to the progress of the other components through the migration plan.
When you reconfiguring existing infrastructure, you can decommission unused or outdated components according to the number of the components that you must reinstall. Before a VM is powered off for the last time, back it up to ensure that you can recover it as needed.