DSO to Cloud Migration
Frequently Asked Questions

 

Why are we doing this project?

The university was exposed to a significant service outage in September 2021 and would like to reduce its reliance on aging on-premises equipment.  Moving to the cloud gets us out of the datacenter business and allows UCF IT to improve services to the campus community.

 

Why did we choose Azure as our primary cloud destination?

UCF already has a significant presence in Azure with nearly 200 servers hosting dozens of workloads. We also have significant expertise in Azure, first deploying resources to the Azure cloud in 2015. With many of our enterprise services running natively in Azure (e.g. identity, email, Teams) it made sense to also leverage Azure for infrastructure.

What are the goals of this project?

To increase reliability and sustainability and enhance service excellence on all information technology systems across the university by shifting toward the cloud. The following goals were developed for this project?

• Replace obsolete equipment and technology
• Eliminate single points of failure
• Enhance or implement security posture to protect the university and its users of technical systems.
• Adopt new cloud skills across university staff
  
  

What is changing?

UCF IT-hosted servers at DataSite Orlando (DSO) will be migrated to UCF’s Azure infrastructure, hosted in the US East 2 region with an average round-trip latency of 25-30ms from campus.

Servers will be migrated to new IP spaces, meaning IP addresses will change. Security posture will be migrating along with the workloads and will need to be updated to reflect the new address space.

We are proposing the elimination of OS firewalls in favor of a combination of Azure firewall options.

What is NOT changing?

Server names, your data, and access to your servers will remain the same.

What is the time frame for the migration?

The first phase of the project is to move every server that is not directly tied to campus ERP systems from November 2022 to September 2023.

What will remain on campus?

Systems that will remain on-campus after the migration to Azure include core services and highly network-dependent services such as Active Directory, DNS, DHCP, voice systems, network management tools, and systems tied to physical campus security.

What is UCF's connectivity to Azure?

UCF is setting up a redundant 10Gbps ExpressRoute Direct connection to Azure that runs through Miami and Ashburn, VA.

All traffic to the private IP space (172.24.0.0/12) will flow over the ExpressRoute connection. This includes traffic to servers in Azure as well as traffic to PaaS and SaaS services with a private endpoint on our network.

All traffic to the public IP space will go over the public internet, or Internet2 for those on the campus network. This includes existing traffic to services like Outlook, OneDrive, Sharepoint, and Teams as well as any servers in Azure with a public IP.

How will systems be moved to the cloud?

We will be using a tool called "Azure Migrate", which is similar to the tools we used to migrate systems in the past. It will perform a bit-by-bit copy of a virtual machine from DataSite Orlando to Azure. Server names will not be changed during this operation, but IP addresses will need to change.

 

What will change with the move to the cloud?

• Cost and billing: We expect most customer workloads to cost less after the move to Azure.
• IP Address: Azure resides on a new network range, spanning 172.24.X - 172.24.X. All systems migrating to Azure will receive a new IP address, which will impact multiple services and will require touch points with DNS, host-based firewalls, and network firewalls.
• Public IP Address: Existing public IP addresses from DSO cannot be ported to Azure. A new public IP will be created for servers.
• Network security: UCF’s Azure design will introduce Azure firewall premium which includes firewalling capabilities and intrusion detection and prevention systems (IDS/IPS) for cross-application communication. For communication within a specific application architecture, traffic will not flow across the Azure firewall and will only use NIC-based Network Security Groups (NSGs) for firewalling.
• Internet Egress filters: We will leverage Azure firewall to filter traffic to and from the internet.
• Latency: Latency between campus and Azure averages 25-30ms.
• Performance: Azure allows us to achieve virtually any desired level of performance, but our approach will be to right-size to optimize both performance and cost.
• Storage: Azure offers a wide range of HDD and SSD options including standard, premium, and ultra-performance disks to meet any performance demands.
• Load Balancers: F5 load balancers are up and running in Azure. Systems behind the F5 at DSO will be placed behind the F5 in Azure with a similar configuration.
• SQL databases: We will be running a data migration tool to determine the best destination for each SQL database, whether that be on a server, in Azure SQL, or Azure SQL Managed Instance.
  
  

How is UCF moving to Azure?

UCF will be working with a partner (Accenture/Avanade) who has experience with thousands of migrations. We will be leveraging their expertise to perform test migrations prior to a full migration of your workloads. If any issues are found, a server can quickly be failed back to DSO and tried again later.

We will be using the Azure Migrate tool to migrate machines. A test migration will be performed to ensure servers boot up in Azure and a network test will be performed to ensure they can reach all required network destinations prior to the final migration.

Migrations will be scheduled once application owners fill out a survey and a follow-up interview is scheduled to go over the workload and its dependencies.

What can I do to prepare?

• Baseline functionality – Make sure your app is working as expected before we begin efforts to move it.
• Baseline performance – Take note of any scheduled jobs or measurable system performance in your current configuration so it can be measured again after the migration to Azure to confirm there are no issues.
• Baseline dependencies – Knowing what databases, servers, and cloud services your applications need to access will help ensure they work as expected after the move.
• Baseline network security – Servers will be moving behind new networks and firewalls, so any existing network and host-based firewall rules must be noted to prepare for the changing IP addresses.
• Baseline Data Flows - Data flows and/or architectural diagrams showing network connections of your systems will be beneficial in cases where network traffic is not performing as expected. You can plan by documenting information about what internet sites, systems, or devices to which your application needs access.
• Define acceptance criteria - what does a successful migration to the cloud look like for your application? What functionality must be present for you to sign off on the move?
• Develop an application checklist or test – Once your application is moved, you’ll want a quick way to validate your acceptance criteria. A script or checklist to test your application’s functionality will ensure your post-migration checks go smoothly. Run the test before and after the move.
• Finally, never hesitate to reach out for assistance! We do our best to answer all questions.
  
  

Will I need additional technical skills?

The closer you work with infrastructure (e.g. servers, networks, firewalls) the more new Azure-specific skills will be required. We are asking internal staff on this project to at least complete the AZ-900 training and certification path. Additional specialization paths are available after AZ-900 is completed.

Where can I learn more about Azure?

• UCF has access to Microsoft's Enterprise Skills Initiative (sign in with firstname.lastname@ucf.edu), which offers free training and certification exams via vouchers. 
• Microsoft Learn is a great free resource that covers a number of Azure-specific areas.
• Microsoft's Weekly Azure EDU Hour call every Friday at 2 PM is a good place to stay updated on the latest Azure topics updates and focused topics.
• John Savill's Technical Training on youtube is one of the best deep-dive training resources for Azure.
• Free Microsoft Azure resources for EDU customers
• For additional training resources, including cross-training opportunities, reach out to us via the "Cloud Infrastructure" Teams channel under the Campus IT Community Team.

What happens during a migration?

• Migration night: Workloads are migrated between 11 PM and 7 AM from DSO to Azure. The old VMs at DSO are powered off and a final replication is done to Azure where the VM will be powered up on its new Azure network.
• Migration day: A workload validation call will be scheduled at 8 AM on the migration day to validate each workload. We ask all workload owners to clear their calendars for that morning to allow for ample time to troubleshoot and report issues so we can clear any firewall or other technical blockers in real time.
• Post-migration: We are asking for ServiceNow tickets to be submitted for all issues that arise after migration day. We cannot properly prioritize our daily work with requests from previous migrations coming through in the same chat/channels we are using for current migration day activities.

 

Technical Lessons Learned

• • How are LDAP binds impacted?
    • When applications using LDAP binds move to Azure, use “useast2.azure.aka.net.ucf.edu” for Azure US East 2 or “centralus.azure.aka.net.ucf.edu” for Azure US Central as the new LDAP server name instead of “net.ucf.edu” or “aka.net.ucf.edu” or “akadso.net.ucf.edu”
  • What should I do to prep IIS?
    • Check site/IP Bindings
      • All IIS bindings need to be checked and moved to new IPs if they are bound directly to an IP and not to “*”
    • Check IP and Domain Restrictions
      • All restrictions need to be updated for any IPs that have moved or changed.
    • Check Certificates
      • When changing IIS bindings, document which certificates are bound before the changes
    • Check NIC metrics for multi-NIC configuration
      • Ensure NIC metric values are properly set within the OS to retain traffic flowing in and out of the same NIC