Introduction

In the previous article, we introduced Azure SQL and its three primary deployment options:

One of the most important decisions when moving SQL Server workloads to Microsoft Azure is selecting the right platform.

Choosing the wrong platform can result in unnecessary migration effort, higher operational overhead, performance limitations, or unexpected costs.

This article explains the differences from a practical DBA and migration perspective.

1. Azure SQL Database

Azure SQL Database is a fully managed Platform as a Service (PaaS) offering.

Microsoft manages the underlying operating system, hardware, database engine infrastructure, patching, and much of the high-availability architecture.

The DBA primarily focuses on:

A typical architecture is:

Application
     |
     v
Azure SQL Database
     |
     +---- Backup
     +---- Monitoring
     +---- Security
     +---- High Availability

When should you consider Azure SQL Database?

Azure SQL Database is particularly suitable for:

The major benefit is reduced operational overhead.

2. Azure SQL Managed Instance

Azure SQL Managed Instance is also a PaaS service, but it provides a broader set of SQL Server capabilities than Azure SQL Database.

This makes it particularly interesting for organizations migrating existing SQL Server applications.

For example:

Existing SQL Server
        |
        | Assessment
        v
Azure SQL Managed Instance
        |
        v
Application

Managed Instance can reduce the number of changes required during migration compared with moving directly to Azure SQL Database.

It is therefore commonly considered when the existing SQL Server environment depends on features that are more closely aligned with an instance-based SQL Server architecture.

3. SQL Server on Azure Virtual Machines

SQL Server on Azure Virtual Machines is an Infrastructure as a Service (IaaS) model.

You essentially run SQL Server on an Azure VM.

The architecture looks like:

Application
     |
     v
Azure VM
     |
     +---- Windows/Linux
     |
     +---- SQL Server
     |
     +---- Data Disks
     |
     +---- Backup
     |
     +---- Monitoring

This provides the DBA with significantly more control.

You can manage:

However, that flexibility also means additional administration.

4. PaaS vs IaaS

The fundamental difference can be summarized as:

Area

Azure SQL Database

Azure SQL Managed Instance

SQL Server on Azure VM

Service model

PaaS

PaaS

IaaS

OS management

Microsoft

Microsoft

Customer

SQL Server installation

Managed

Managed

Customer

Instance-level control

Limited

Higher

Highest

Infrastructure management

Low

Low

High

SQL Server compatibility

Application dependent

High

Highest

Migration effort

Can be higher

Often lower for existing SQL Server

Usually lowest from infrastructure perspective

Custom OS configuration

No

No

Yes

The important point is that more control also means more responsibility.

5. Migration Assessment

Before selecting a platform, perform a SQL Server assessment.

A typical migration assessment should examine:

Database compatibility

Check:

Workload characteristics

Understand:

Availability requirements

Determine:

These requirements should be defined before selecting the Azure architecture.

6. Example Migration Scenarios

Scenario 1: New application

A company is building a new application and does not require extensive SQL Server instance-level functionality.

A managed database service can reduce infrastructure administration.

Possible architecture:

Web Application
      |
      v
Azure SQL Database
      |
      +---- Azure Monitor
      +---- Microsoft Entra ID
      +---- Private Endpoint

Scenario 2: Existing SQL Server application

A company has a large SQL Server database with multiple existing dependencies and wants to minimize application changes.

Azure SQL Managed Instance may be considered as part of the migration assessment.

On-Premises SQL Server
          |
          | Assessment
          v
Azure SQL Managed Instance
          |
          v
Application

Scenario 3: Maximum SQL Server control

A workload requires operating-system access, custom SQL Server configuration, or other capabilities that require infrastructure-level control.

SQL Server on Azure VM may be appropriate.

Application
     |
     v
SQL Server
on Azure VM
     |
     +---- OS
     +---- SQL Server
     +---- Storage
     +---- Backup
     +---- Monitoring

7. Don't Choose Based Only on Database Size

One common mistake during migration planning is selecting the platform based only on database size.

For example:

"The database is 2 TB, so we should use a SQL Server VM."

Database size alone does not determine the correct platform.

A better assessment considers:

Database Size
      +
Performance
      +
SQL Features
      +
Application Dependencies
      +
HA/DR
      +
Security
      +
RPO/RTO
      +
Cost
      +
Operational Requirements

The result should determine the target architecture.

8. Migration Assessment Workflow

A practical migration process can look like this:

Discover
   |
   v
Assess
   |
   v
Identify Compatibility Issues
   |
   v
Analyze Performance
   |
   v
Determine HA/DR Requirements
   |
   v
Estimate Cost
   |
   v
Select Azure Platform
   |
   v
Pilot Migration
   |
   v
Performance Testing
   |
   v
Production Migration

This approach reduces the risk of discovering major compatibility or performance issues after production migration.

9. The DBA's Role in Azure Migration

A successful migration requires more than simply moving database files to Azure.

The DBA should be involved in:

The DBA's role therefore moves from traditional infrastructure administration toward database architecture and workload optimization.

Conclusion

There is no single Azure SQL platform that is suitable for every workload.

The three main options serve different purposes:

Azure SQL Database provides a highly managed database platform.

Azure SQL Managed Instance provides a managed environment with broader SQL Server compatibility.

SQL Server on Azure VM provides the greatest level of control but also requires the most operational management.

The right choice should be based on application requirements, SQL Server compatibility, performance, availability, security, operational responsibility, and cost rather than database size alone.