John & Richard,
I've already moved several clients from on-prem or hosted facilities to Azure.. I had never seen the document that Derek posted here before, but everything is by the book and exactly how you're supposed to do it.
About the licensing, it all depends if you're subscribed to a larger SLA for licensing or not, but in general, it's recommended to pay the licenses directly with the VM's you setup from the Azure store. There are hundreds of Azure Templates all pre-configured with the software, the only difference is that if you take one with SQL installed already, you might have to reconfigure it to fit your very specific needs for GP, as out-of-the-box it's very standard.
I always recommend a multi-VM approach with the back-end SQL data server and a front-end TS server for the users to connect to. It's likely that the client will be using O365 (now Microsoft 365) licenses for Excel & Word, so there are some particularities to consider when deploying on a TS server, to avoid multiple licensing for each and every user.
Depending on how large the user count will be, you may want to add a 3rd VM for applications (like MR 2012, Web Services, Integration Services, etc..) to not put all the load on the SQL server.. though it's all about budgeting and costs, since firing up a new VM will add its load of $$$ to the TCO. Most of my small to mid sized businesses get away with a 2-VM's setup.
The most tricky part is the AADS integration with the existing domain and/or the O365 accounts, and of course securing the whole network in the cloud so only the computers from the internal company network can actually access the Azure environment thru a dedicated VPN setup. If you're not familiar with all things networking and security, you better hire a good Azure network specialist. Or pay Microsoft support to assist you with the setup.
To get an idea of the TCO, use the Azure cost calculator to get a rough estimate of your monthly bill to come. Microsoft offers some significant rebates if you commit for long term and pay up-front for 1-3 years ahead. The savings can be up to 30% if not mistaken compared to the PAYG (Pays As You Go) model.
Everything else is pretty much identical with an on-prem setup when it comes to deploy the various services around GP, as described in the document.
The major difference when using SQL on Azure (and having the VM declared as such), is that you'll be able to leverage the Azure Data backup framework and get all your scheduled backups handled directly by Azure (instead of creating maintenance plans in SSMS), which offers also redundant data storage for a better DR coverage. What you still need to plan locally on the SQL VM is the regular DBCC checks, as this isn't yet offered in the Azure DB maintenance. The annoying thing is that the backup tasks from the Azure side don't offer as much flexibility for the schedule, but they are very fast.
Since the document is already 5 years old, you may want to dive a little bit more into the various VM sizes that are currently offered on Azure, as they evolve quite frequently. As for the storage space, be careful to chose the proper type (HDD, SSD or Premium SSD) as there is a hefty price tag attached to premium SSD, which turns out to be the default storage type when creating a new VM or storage space. The OS disk running the VM ususally doesn't need to be a premium SSD drive, as there isn't much going on that drive (but again, it depends on how your SQL is setup). Most data drive get pretty descent performance with regular SSD drives and they are 30-50% cheaper than premium SSD's. The biggest cost on every VM is likely to be the licensing of SW and running CPU's. Chose wisely.
Hope this helps.
