James Thew - Fotolia
A Windows admin's work isn't done after an RDS migration is complete. Next you'll need to verify that the new server is running as expected. And testing RDS can be a challenge.
Decisively testing a remote desktop update can be tricky, especially when multiple roles are moved to another platform. Microsoft typically recommends a pilot program that allows IT staff to test limited connections and then scale up the number of connections once they verify each function. Test the migrated server completely before placing it into production.
After verifying that the server is in production, you can reallocate the old server to other tasks. You may have to remove the old server from the domain, disconnect it from the network, shut down, and possibly remove it from the rack for inspection and upgrades. Then you can reload operating systems, hypervisor, workloads and so on, and return to service.
An RDS migration has a few caveats. First, it's best to perform a migration between two Windows Server 2012 R2 systems -- or from Windows Server 2012 to Windows Server 2012 R2. Because of compatibility issues, RDS running on Windows Server 2008 R2 can only move Gateway and Licensing roles to Windows Server 2012 R2. Migration is also a role-by-role process, so only one role can be migrated at a time starting with Connection Broker and then moving sequentially through the subsequent roles -- though Licensing and Gateway can be migrated anytime.
Finally, RDS services won't be available during the migration process, which can take upwards of several hours. So plan migration sequences for times when RDS (and other software that depends on it) is least impacted.