Migrate virtual machines from development to production
Administrators must prepare carefully before moving test or development VMs to production. Check connectivity, security, compliance and licensing before beginning a migration.
Before administrators can migrate virtual machines from a development or test environment to production they must perform a variety of checks to ensure the migration will be successful.
One reason Docker containers are popular is that they enable IT pros to move workloads from test and development environments to production without modification. Unfortunately, the same isn't always true for VMs. In most cases, there are a number of different things an admin must consider before moving test/dev VMs to production.
Check connectivity with virtual network adaptors
If the test/dev environment is separate from the production environment, a VM's virtual network adapters are unlikely to automatically connect to the production network. In some cases, resolving this issue might be as easy as pointing the virtual network adapter to a different virtual switch. In other cases, it might not be that simple.
For instance, an administrator might have to reset any statically assigned IP addresses or domain name system mappings. In special circumstances, the administrator might even need to recreate application-level bindings.
Admins will likely need to change a VM's domain membership to migrate virtual machines to production. Before admins can join the VM to the production Active Directory, they will need to remove it from the lab domain.
Fulfill security and compliance standards
Most organizations have rigid security and compliance requirements for production workloads. Before admins can migrate virtual machines to a production environment, they must check compliance to ensure new VMs meet all the requirements. This check should come before the use of an automated tool, such as Windows Desired State Configuration.
If the VMs comply with the organization's requirements, then the migration planning process can begin. If a VM isn't compliant, the compliance problems will require resolution, and that VM will need thorough testing to ensure the changes don't cause any problems for the VM's workload.
Review licensing, agreements and resources
The VM's OS and any software running on it require proper licenses. A license that enables software to run in a test/dev environment might not enable that same software to run in production.
Software from a Microsoft Developer Network subscription often has a license for lab use, but not for production use. And if a Hyper-V host runs under Standard Edition licenses, there is a limit to the number of Windows VMs that the host can run without needing additional licenses.
The VM's OS and any software running on it require proper licenses.
Some VMs might have service-level agreements (SLAs). SLAs are unlikely to affect a VM's configuration -- unless they require a guest cluster -- but they can determine which hosts are eligible to run the VM, and whether high availability is required to migrate virtual machines.
Anticipate the level of VM usage. Test/dev VMs don't have to support user workloads, so they might not have as much memory or as many CPU cores as production VMs. If such a VM is migrated to a production environment, its lack of hardware resources could cause serious performance problems. It's important to validate whether the VM's current resource allocation is adequate to support the anticipated workload.
Unlike a containerized environment, transitioning test/dev VMs to production is rarely as simple as performing a live migration. There are numerous things that admins must check before they migrate virtual machines to ensure they will be compliant, properly licensed and adequately provisioned.
