Migration scenarios can be broadly categorized as rehosting or re-platforming. Rehosting, also referred to as "lift and shift," is most often associated with changing the underlying infrastructure, as in rehosting an on-premises database on an Azure virtual machine. A VM doesn't care what database engine it is running, so after configuring the relevant database server software, you can restore almost any on-premises database to the virtual machine. How you implement a "lift and shift" operation in this scenario is very flexible. There are several Microsoft and Azure tools that can assist, as well as the databases' native or third-party tools, to get the job done.

SQL Managed Instance is nearly 100 % compatible with SQL Server without the overhead of managing a virtual machine. While classified as platform as a service, if your on-premise databases are currently supported versions of SQL Server, migration can also be a lift and shift exercise.

SQL Server databases reliant on third-party or custom software libraries for extended functionality will be limited to rehosting unless alternative solutions compatible with the selected Azure target can be implemented.

Re-platforming encompasses all scenarios where you migrate from a database engine that isn't supported either as a managed instance, or you're migrating to Azure SQL, Azure MySql, or Azure PostgreSQL. Even under the most favorable circumstances, that is, your on-premise database is compatible with Azure SQL, it is not possible to do a backup and restore. The closest you can get to that is exporting the on-premise DB to a BACPAC file and then importing that file to an Azure SQL database.

I'm talking about a one-time migration in all of these scenarios, where databases are backed up in one environment and restored to Azure in a time-sequential operation. The elephant in the room is the overall system downtime. When a combination of data volume and a limited migration time window rules out the on-shot strategy, you have a couple of options depending on your situation. You could employ a staggered approach, migrating slow-changing data while the on-premise production databases continue to operate, leaving only frequently changing data to migrate during the downtime switch over. This strategy depends on data usage patterns and works best with transactional data where records are predominantly added instead of existing data edited. In the context of SQL Server, a variation to this approach is employing the disaster recovery technique of restoring a full backup, followed by an incremental backup and finally a transaction log backup. The online version of migrating to Azure SQL managed instance through the portal's Data Migration Service is an automated version of the SQL Server disaster recovery technique just described.

If you have no tolerance for downtime, no matter how brief the cut-over period, there are alternative migration scenarios based on the target database. When the source and target are SQL Server instances, you can use on-premise backups to get you most of the way, then set up failover clustering, as in the high availability solution, to synchronize remaining data in real-time. There is no Azure or Microsoft real-time solution for migrating from an on-premise non-SQL Server to the equivalent hosted on an Azure VM. In this case, you will need to investigate high availability or replication solutions offered by the database vendor.