Organizations like ours constantly demand new technologies and techniques from our Cloud vendors. There are many Clouds out there, but Azure has been a trusted vendor since 2008 with 722.22 million users in 2024 and a reach that extends to 85% of Fortune 500 companies. When it upgrades capabilities, it gives organizations like ours new technologies and techniques to bear against our business problems.

Occasionally, these upgrades are mandatory. Just like AWS, Azure needs to move all the Classic workloads to a Virtual Network just to have enough IP addresses to meet their customer needs. Our client had one such environment which was in dire need of upgrade.

Moving an application to a Virtual Network (VNet) in Azure provides numerous benefits, including enhanced security, isolation, and control over network traffic. Most importantly, it includes a performance boost for your Customers.

After shifting to VNet, our client saw a 9% boost in performance over Azure Classic.

The migration requires careful planning and execution when dealing with a complex web application involving components like Redis Cache, MySQL, and SQL Server databases along with a backing API layer. This post outlines the migration steps and key considerations for lifting and shifting such an application into an Azure VNet.

Case Study: Complex 3+ Tier Web Application

Our customer had a typical 3 tier web application with a couple special add-ons. A WordPress CMS rendered the HTML while a CDN optimized delivery of the HTML / Media files. The data intensive part of the website was powered by a RESTful API backed by a SQL database. Other services, like an Elasticsearch index and message queues, rounded out the stack.

Why Move to an Azure Virtual Network?

• Performance: A performance boost may be expected as the components can talk to each other over the local network.
• Enhanced Security: VNets allow you to create a private network space in Azure. This enables you to control inbound and outbound traffic using Network Security Groups (NSGs) and firewalls.
• Isolation: You can isolate your applications and services from the public internet and other Azure resources, reducing the risk of unauthorized access.
• Hybrid Connectivity: Establish secure connections between your on-premises network and your Azure VNet using VPN or Azure ExpressRoute.
• Network Control: Gain full control over IP address ranges, subnets, and routing, allowing you to design your network architecture to meet your specific needs.
• Scalability: Ability to create auto-scaling rules to handle increased traffic at peak times that provision the number of instances beyond Azure Classic limits.

SNAT use Reduction: Anytime the application needs a public IP address (ie, reaches outside the VNET), Azure will assign it an SNAT connection but Azure will limit how many are available. Using a VNET for your intra-component communication avoids public IP addresses completely.

Planning Your Migration

Migrating a complex web application requires meticulous planning, especially for larger and more complex applications in a complex corporate environment.

It took us 10 weeks to migrate a 5 tier web application that included many lower environments and crossed internal organizational boundaries.

Not all Azure services are the same between Classic and VNET-enabled environments. You may be forced to upgrade so plan your migration steps carefully.

Here are the essential steps:

1. 1. Inventory Your Resources:
      • Identify all components of your web application: Web app, API layer, Redis Cache, MySQL database, and SQL Server database.
      • Document their current configurations, dependencies, and network settings.
      • Determine the IP addresses or service endpoints currently in use.
   2. Design Your VNet:
      • Choose an appropriate IP address range for your VNet.
      • Create subnets for each component of your application (e.g., web app subnet, database subnet). This allows you to apply different security rules to each subnet.  
      • Plan for Network Security Groups (NSGs) to control traffic to and from each subnet.
      • Ensure that your component subnets have routes configured to talk to each other.
      • Pick Azure-managed DNS (suggested approach to simplify maintenance) or your own.  
   3. Security Considerations:
      • NSGs: Create NSG rules that allow only necessary traffic to each resource. For instance, the web app should only receive traffic on ports 80 and 443, and databases should only be accessible from the API layer.
      • Firewall: Consider deploying Azure Firewall or a Network Virtual Appliance (NVA) for more advanced traffic filtering and threat protection.
   4. Build Your Project Plan:

• • • We estimated our project to take 2-4 weeks with these high-level tasks:
      • ARM template development
      • Database migration
      • Static file migration
      • App Service configuration
      • Front Door migration 
      • Load/performance testing
      • Functional testing

We missed our target mainly for two reasons: SQL Server migration and upgrading Azure component versions. This is covered in detail in the “Things that Tripped Us Up” section.

Migration Steps

Here’s a general approach for migrating your complex web app:

1. Create the Virtual Network:
   • In the Azure portal, create the VNet and configure the IP address range and subnets.
2. Deploy Resources into the VNet:
   • Databases (MySQL and SQL Server):
     • For Azure SQL Server, you can directly create instances within your VNet or use Private Endpoints.
     • For Azure Database for MySQL, consider deploying it within a VNet or using VNet Service Endpoints.
     • Migrate your existing database data to the new instances in the VNet.
     • When using SQL Server consider using a Hyperscale payment model. This allows the use of geo replicas which can make it easy to migrate data.
   • Redis Cache:
     • Create an Azure Cache for Redis within your VNet, configuring it to be accessible only from your web app and API layer subnets. Redis needs to be created outside the VNET then joined via a Private Endpoint.
   • API Layer and Web App:
     • Deploy your API layer and web app into their respective subnets within the VNet.
     • Update the application configurations to point to the new database and Redis Cache endpoints.
3. Configure Network Security Groups (NSGs):
   • Create and apply NSGs to each subnet.
   • Set inbound and outbound rules to allow only essential traffic.
   • For example:
     • Web App Subnet: Allow inbound traffic on ports 80 and 443 from the internet. Allow outbound traffic to the API layer and Redis Cache.
     • API Layer Subnet: Allow inbound traffic from the web app subnet. Allow outbound traffic to the databases.
     • Database Subnets: Allow inbound traffic only from the API layer subnet.
4. Testing:
   • Thoroughly test your application in the new VNet environment.
   • Verify that all components can communicate with each other.
   • Check for any connectivity issues or performance bottlenecks.
   • Use Azure Load Test tool to execute your JMX scripts and review the performance metrics of your components. Establish a baseline, then make your adjustments and run the tests again to compare if the changes you made improved performance.
5. Cutover:
   • Once testing is successful, update your DNS records to point to the new web app endpoint in the VNet.
   • Monitor the application closely after the cutover to ensure everything is running smoothly.

Key Considerations

• Service Endpoints vs. Private Endpoints:
  • Service Endpoints extend your VNet private address space and the identity of your VNet to the Azure services over a direct connection.
  • Private Endpoints use a private IP address from your VNet to bring the service into your VNet, allowing access via private link.
  • Choose the approach that best suits your security and connectivity needs.
• Connection Strings:
  • Ensure all connection strings in your application configurations are updated to reflect the new endpoints for databases and Redis Cache.
• DNS Resolution:
  • Consider using Azure Private DNS to resolve internal domain names within your VNet.  Azure will manage the mappings between your App Service domains and the underlying resources.
• Monitoring:
  • Set up Azure Monitor to track the performance and health of your application and its components within the VNet.

Things that Tripped Us Up

• • SQL Server Migrations – We migrated our lower environments with traditional SQL Server techniques like running a backup, shifting the ‘bacpaq’ file to the new environment, then restoring the database. Our production migration was very painful because it would take 2 hours before it failed. After talking to Microsoft Support the first time, it failed 9 hours after using their suggested tweaks. Finally, they suggested using the replica feature which is the technique we referenced earlier. This allowed us to shift our data without any downtime of the websites.

• Azure Service Upgrades – We also attempted to upgrade several key components during this process and found that simply made our project take longer and caused a lot of heartache. For example, we were moving from Azure Front Door classic to the new Azure Front Door Premium, which are not compatible, and this caused us to completely rebuild our Front Door configuration (very complex!) Then we had to play “wack a mole” as we needed to disable / exclude some of the new Front Door managed rules that blocked legitimate website traffic.

Conclusion

Migrating a complex web application to an Azure Virtual Network involves careful planning and execution. By inventorying your resources, designing your VNet, and implementing strong security measures, you can successfully lift and shift your application while enhancing its security, isolation, and manageability. Thorough testing and monitoring are essential to ensure a smooth transition and optimal performance in the new environment.

Use our team’s process and documentation to help your team in migrating to VNet. Want us to assist or do the migration for you? Reach out anytime for estimates, we are here to build technology together.