Azure Migration

A list of specific servers identified for this effort is available here.

Yes, there is the potential for downtime associated with the migration. For a normal migration, the outage is expected to be the equivalent of a server reboot, i.e. a few minutes. A server reboot is necessary to allow your virtual server to properly recognize its changed circumstances.

Any longer downtime would be unexpected and because of unforeseen problems. See What will happen if something goes wrong with the migration?

Yes, servers will remain on the UW Network.

However, the IP address for your server will change. If that IP address has been hard-coded anywhere, that could introduce a potential for problems. We will update the DNS record for your server as part of the migration. If you think an IP address change could cause problems, we’d love to hear about that.

There should be no decrease in performance and if needed, we can easily increase the capacity available after migration.

Networking between UW on-campus networks and Azure is expected to be performant, with sufficient bandwidth and relatively low latency. If your server has reliant on other on-premises resources with a large data payload, we want to look more closely to see if there will be an impact.

For example, across all the servers moved, we won’t be using the TSM backup service we have used to eliminate the need for backup data to traverse that network link; instead we’ll be using the Azure native Azure Backup for server backups. This won’t impact our ability to recover your server or data, but it is a change we are making partly because of the network.

The IP address for your server will change. If that IP address has been hard-coded anywhere, that could introduce a potential for problems. We will update the DNS record for your server as part of the migration. If you think an IP address change could cause problems, we’d love to hear about that.

We have not finalized the schedule for server migrations, however, we plan to:

• Group servers which have dependencies and where possible by customer
• Leverage existing Windows Update time windows for your servers

We will contact you with more specific details around timing in the coming weeks.

UW-IT in partnership with Microsoft will be performing the server migrations, so you have no actions to take for that. If you have concerns about this migration process, you can contact help@uw.edu with questions about the Azure Migration project. Please be sure to include “Windows Managed Server Azure Migration” in the subject line and include your server name.

There will be a failback option if anything breaks because of the migration–a non-running copy of your VM will remain on-premises. We’ll remove that copy at some later point after we all have confidence we don’t need to failback. Should the migration cause a significant problem, we can quickly start up this copy of your server to get your server back in business.

If a non-critical issue is caused by the migration, we’ll work closely with you to help resolve that issue. Regardless of the technical problem, we will be the point of contact to help get the issue addressed.

If you have specific timeframes during which your server should not be offline, we’d love to hear that, so please reach out to us. The bulk of the migrations for this wave 1 of server migrations will happen during February.

In general, we’ll look at when your server is currently applying Windows Updates along with any required restart, and try to target your migration for shortly after that time of day to avoid introducing a new interruption at a different time of day. But we’ll also factor in whether your server has dependencies on other servers, so we group those servers together to avoid potential network performance issues, as well as factoring in the overall needs of other customers, and any no-go times you tell us.

We’ll share with each of you the specific day and time planned for your server when we’ve got more awareness of customer’s needs.

Windows Managed Server provides Windows Firewall based capabilities for customers. As a host-based firewall, all configuration will follow the server regardless of where it is hosted.

A few customers additionally leverage the UW-IT Managed Firewall, which is a network appliance based firewall. UW-IT Managed Firewall does not have an Azure solution. Windows Managed Server is looking into providing this capability for customers who have this kind of need. To the best of our knowledge, we haven’t included servers which have a UW-IT Managed Firewall in the wave 1 of migrations, so we don’t think this applies to your servers, but we’d love to hear otherwise.

There is also the possibility that your server provides services to partners who have a firewall, and those partners have a firewall configuration tied to your server’s existing IP address or DNS name. In this scenario, if the firewall configuration is DNS based, no additional work is needed. If that other firewall’s configuration is IP based, then we’ll need to work with you to ensure the new IP address is reserved and communicated to your partners with sufficient time for them to make those changes before the server migration. Since this kind of configuration doesn’t usually involve the Windows Managed Server team, we usually aren’t aware of it, so would need to rely on your awareness to ensure that issue is addressed.

Data for servers hosted in Azure will reside in one of the following Azure regions: West US 2 (Washington), Central West US (Wyoming), or West US 3 (Arizona). You can refer to https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/#geographies for some additional details on Azure regions.