Forum Discussion
John Wildes
Jan 29, 2019Brass Contributor
Cutover Timeout recommended settings
Hello I'm trying to migrate a server to Azure. I'm in the cutover phase, it has a default timeout of 2880 minutes, which is 48 hours. Personally I can't have a file server "offline" for 48 hours d...
NedPyle
Microsoft
Jan 30, 2019Ah good - I was worried our cancel at the 1 hour work was totally being ignored. I think our UI could be much more clear here, that’s good feedback.
We intentionally prevent the source from keeping the same IP address because many apps/scripts/users will continue to talk to the decommissioned source after cutover. In the new feature where you can skip migration of the network we will still require that. But we’re thinking of adding a 3rd “do nothing at all here and let admins operate at their own risk” mode.
If you try this again, if you get to the 44% phase, set the destination VMs IP back to working and let it register DNS, then the migration should start working within the dns replication and timeouts. We have that overall cutover timeout so high because many environments will not have converged their AD and DNS for many hours.
Do you have a screenshot of what you mean about the validate?
We intentionally prevent the source from keeping the same IP address because many apps/scripts/users will continue to talk to the decommissioned source after cutover. In the new feature where you can skip migration of the network we will still require that. But we’re thinking of adding a 3rd “do nothing at all here and let admins operate at their own risk” mode.
If you try this again, if you get to the 44% phase, set the destination VMs IP back to working and let it register DNS, then the migration should start working within the dns replication and timeouts. We have that overall cutover timeout so high because many environments will not have converged their AD and DNS for many hours.
Do you have a screenshot of what you mean about the validate?
John Wildes
Jan 30, 2019Brass Contributor
I can see why you would do what you do by default with the changing of the IP address. In my case I would power off the old server after cutover to preserve state in case you had to roll back. I do think having a 3rd option of letting the admin proceed at their own choosing, highlighting some risks of proceeding without the recommended changes would be good practice. Allows for flexibility.