Quickstart guide – ISV going from OnPrem to Azure

Are you an Independent Software Developer (ISV) currently creating, updating, and maintaining web applications in an on premises environment, using Windows Server with Internet Information Services (IIS) and Microsoft SQL Server, looking to migrate to Azure?

Do you have little to no experience with Azure, but you want to drop the legacy and take advantage of what the cloud can give you? Then this guide is for you. Here I'll list some important starting points, and hopefully give you some information that will help you from making the traditional rookie mistakes. 

Azure Structure / Hierarchy 

First, a short intro on how Azure is built up. When I started working with Azure it took me a long time to understand this part. 

• On top you have your Directory, a.k.a. Azure AD, a.k.a. Tenant. This is your unique ID at Microsoft cloud services (Azure, Office 365, Exchange Online etc.), where your users and groups are placed. Your tenant primary name is "<your_chosen_tenant_name.onmicrosoft.com".
• Inside a tenant, you have Subscriptions (among other things).
• You can have multiple Subscriptions with different or same subscription models within the same tenant.
• You could for instance have a (or multiple) Pay-as-you-go subscription(s) living in a tenant together with a (or multiple) CSP subscription(s).
• You MUST have a directory / Azure AD / Tenant for a subscription.
• Inside Subscriptions you have Resource Groups and Resources. 
• ALL resources must reside inside a Resource Group. 
• Similar resources/ resources that belong to the same parent/ solution, should reside inside a dedicated resource group.
• Example (Where "<company_short_name>" should be replaced with your company short name, or other identifier. We could use "irnst" for "Ironstone".
• "<company_short_name>-p-network" for everything network. Like Virtual Network, Network Security Groups, VPN Gateways…
• "<company_short_name>-p-management" for everything related to the management of your resources. Like Key Vault, Recovery Services Vault, Automation Account, Update Management…
• "<company_short_name>-p-app" for everything related to the website. Like App Service Plan, or VM if you end up using Virtual Machines with IIS and SQL
• Many resource groups will make your environment tidy and more easily maintainable.

Get these things right from the start 

The first three things you should get right from the start, is: 

• Azure Region. Choose a region and stick to it. Unless you have special needs, we always suggest West Europe. Deploying between multiple regions will create unnecessary delays, and data flowing between regions actually costs
• Naming Scheme. Plan a naming scheme right from the start. Names can't be changed after a resource have been deployed. Morten Reinhardtsen at Ironstone just wrote a nice blogpost about our suggested naming scheme for Azure, take a look: https://www.ironstoneit.com/blog/naming-conventions-for-azure.
• Azure Price Calculator. The golden rule is to always check the price for the resource you are about to deploy. CSP subscriptions will have roughly the same price as Pay as you Go. https://azure.microsoft.com/en-us/pricing/calculator/ 

Basic Infrastructure you'll need in all cases 

Either way, you must have a basic infrastructure in place. You'll most likely need all of these, no matter how you choose to host your website and database: 

• Azure Virtual Network, which will serve as the local network for all your resources
• Divide into subnets
• Secure with Network Security Groupsand/or Application Security Groups (see Network Security Groups link) 
• Azure Recovery Services Vault, for backup of VMs, Blob Storage and more.
• Azure Key Vault, for secure storage of certificates, passwords
• Azure Log Analytics Workspace(A part of the solution named "Azure Monitor") for monitoring your environment. It can be used to monitor everything from Azure AD, VMs, App Services, i.e. pretty much everything. 

Tips for ISVs going from IIS and Microsoft SQL to Azure 

It's preferred to use PaaS (Platform as a Service) over IaaS (Infrastructure as a Service) when possible. It will be cheaper, more scalable, secure, and available (high availability). In addition you don't have to maintain anything but code. It also enables cool features like deploying straight from Visual Studio to Azure App Services. 

• If you are coming from IIS and Microsoft SQL, you should look into making the website run on Azure App Services (Microsoft Docs), and the database on Azure SQL (Microsoft Docs).
• When it comes to migrating existing Microsoft SQL databases to Azure, take a look here: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-cloud-migrate  
• If you can't do Azure SQL, take a look at Azure SQL Database Managed Instance (Microsoft Docs). Here you rent a database where Microsoft maintain the infrastructure (Virtual Machine with Windows Server + Microsoft SQL) for you. Cheaper, more secure and reliable than what you probably would manage to create yourself.

If you end up using virtual machine(s): 

• Always put Virtual Machines in an Availability Set (Microsoft Docs). For multiple VMs doing the same job, like hosting a web page, put all in the same Availability Set to make sure they don't get patched or maintained at the same time.
• There are ready made templates that you can deploy straight to your environment, which include Windows Server 2016 Database and Microsoft SQL 2016 Standard SP2. This is preferred over deploying a VM and installing SQL manually, because with the prebuilt solution you get additional functionality and integration with Azure, like backup and database patching. Search for "SQL Server 2016 SP2 Standard on Windows Server 2016" in Azure.
• If you choose to run your web page on IIS, you should put a Azure Load Balancer (Microsoft Docs) in front of it. It supports NAT rules, health probes, failover/ high availability when using multiple VMs etc. 
• Never put global/ public IP straight on the virtual machine.
• Azure Automation Account, for Update Management(automatic patch/ updates for Windows Server OS), runbooks and more. 
• SSD storage (Premium Disk) is expensive, and usually not needed. Avoid it if you can.
• Turn off virtual machines when they are not in use. This can be automated with PowerShell runbook running from Automation Account. This will save you a lot of cost.

That’s some starting point for you from the top of my head. If you got more questions or need help: Don't be afraid to ask! We are happy to help :)