1️⃣ The most obvious idea: Lift and shift
We choose one of the prefabricated SQL VMs on Azure, backup and restore the databases, change the compatibility level – and we're done. In reality, however, this is not quite as simple. Network aspects, performance requirements and security issues often stand in the way of a fast migration. This necessitates clarification and establishment of high availability during VM operation. The advantage of this variant: SQL Server 2012 can be operated for another three years with extended security updates.
However, there are other possibilities of dealing with the topic of PaaS without concentrating on infrastructure:
2️⃣ SQL Server managed instance
From my own point of view: This is often a very good choice for modelling workloads in Azure while reaping the benefits of the cloud. SQL MI gives you a complete SQL Server instance in the cloud, allowing you to create up to 100 databases. Cross-database queries seen commonly on-premises are thus one of the achievable scenarios. The latest service levels offer a choice of up to 64 vCores and almost 900 GB of RAM – enough for most requirements. Plenty of storage capacity is also offered with SQL MI: Up to 16 TB are available here - that's sufficient space for a small database, also enabling business-intelligence applications.
3️⃣ Azure SQL DBs
If you want to migrate a single database or many small, mutually independent databases, then it's worth taking a look at the Azure SQL DBs. These are available as individual databases or as elastic pools. An advantage of such elastic pools is easy handling of peaks in the respective workloads, due to sufficient capacity provided for all databases by the various pools. It is therefore not necessary to ensure excess reserve capacity in advance for reliability during performance peaks. An interesting variant at the server level in the case of individual Azure SQL DBs: Serverless. If an application only needs a database backend at certain times, then the serverless variant is worth considering. With the help of the "auto-pause" functionality, only storage costs are incurred, without any costs of vCore. This proves ideal in scenarios which are not 24/7.
4️⃣ Azure Synapse analytics
If SQL Server is to operate according to a BI workload, it might be worth considering the fourth variant as an option: Azure Synapse analytics, a service which combines data integration, data warehousing and big data. Synapse is also equipped for future issues such as AI and machine learning. Synapse provides a SPARK engine as well as 2 SQL engines. The serverless engine makes it possible to execute ad-hoc queries to the data lake. Costs are incurred here only per individual query, not per CPU or server, or the like. This is particularly interesting for initial explorations of data. Powerful, dedicated SQL pools technically representing an MPP (massively parallel processing) database are available for the segment involving the actual data warehouse. The greater the quantity of data and the ability to distribute them, the greater the benefit provided by such architectures during queries.