So what makes a good migration test environment?
Here are some things to keep in mind:
- You’ll want an environment that will tell you whether your plans are on track or are going to fail spectacularly. You don’t want to be in the position of having a major blocker turn up during the actual migration that a basic test migration would have identified.
- You don’t need to replicate the final environment in its entirety – your test environment is there for testing.
For example, you might be thinking of deploying an 8 node Hyper-V failover cluster to host the migrated production workloads, with each node having oodles of RAM and processor and disk capacity out the wazoo.
You don’t need to deploy an 8 node Hyper-V failover cluster as your test environment. If you need to test the mechanics of failover, 2 nodes is fine.
The main things you’ll be wanting to check is whether the hardware resources you’ll allocate to each migrated virtual machine workload are adequate and if there is any problem running the migrated workload in the new environment.
Remember also that you’ll be performing tests on a piecemeal basis. You don’t need to run every workload in your test virtual environment at the same time to get an idea of what the hardware utilization will look like. You can run each workload separately in the test environment and get an idea of what the combined resource requirements will be.
In the end, your migration test environment needs be able to host the most demanding individual workload that you are going to be migrating.