Before going on annual leave a couple of weeks ago, I dealt with migrating a static website from a 2008 IIS VM on VMWare to Azure for a customer.
Initially, after scoping and a call with the stakeholders, Storage Account was the best choice to fulfil the following criteria:
- Low cost
- Low footprint
- Easy for non-technical users to upload files
- 14GB of site files
The last point came up slightly later in the process, as it was found that most of the stakeholders were non-technical and had little knowledge of “how” the site worked.
I migrated the site files up to the storage account and used a custom DNS temporarily to present a friendlier URL, although discovered soon after that storage account has a very significant feature set of IIS missing – case insensitivity for file names. Raising this with the stakeholders, and auditing the number of HTML files contained within the subfolders threw back a staggering number of 3512. If there were only a handful of actual HTML files it wouldn’t have been a big issue to rename the files. Further to that, looking into the raw HTML, even file paths use differing case (an unfortunate turn)
I made the decision to completely scrap the storage account website and instead build out App Service. The notable differences from a Storage Account being:
- The ability to specify multiple index file types – this meant we could allow for both index.html and index.htm to cover any variance
- Easier method of uploading – App Service can upload with FTP, whereas Storage Account required Storage Explorer
- Ability to handle mixed case file names and file paths – completely alleviating the issue with the Storage Account, and more closely aligning to the features of IIS
While App Service is more expensive (by a fair margin), it does allow a greater degree of flexibility to a solution over a Storage Account. I would have personally loved it if we were able to get it working with a Storage Account, although ensuring the sheer amount of files and folders were correctly renamed to account for the lower-case only requirement would have been too time consuming in terms of delivery constraints, as well as creating a dependency on the stakeholders to be able to resolve any issues and dependencies that arose from a mass rename action.
To summarise, Storage Account websites would be an excellent choice, provided you understand and design beforehand the necessity of only using lower case naming conventions, and you don’t have a variety of index/root pages. Usually that would be the case in this day and age, although working with migrating websites initially created 10-15+ years ago and not maintained from a developer level can lead to the same issues that I’d experienced with this migration.
