Introduction

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

  • Azure SQL Database

  • Azure SQL Managed Instance

  • SQL Server on Azure Virtual Machines

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:

  • Database configuration

  • Security

  • Performance

  • Query tuning

  • Indexes

  • Data management

  • Cost optimization

  • Monitoring

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:

  • New cloud-native applications

  • Modern application architectures

  • Individual databases

  • Applications that do not require extensive instance-level SQL Server features

  • Organizations looking to minimize infrastructure administration

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:

  • Operating system

  • SQL Server version

  • SQL Server configuration

  • Instance-level settings

  • Storage layout

  • SQL Agent

  • Maintenance jobs

  • Backup configuration

  • Custom monitoring

  • Third-party software

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:

  • SQL Server version

  • Compatibility level

  • Deprecated features

  • Unsupported features

  • Cross-database dependencies

  • Linked servers

  • SQL Agent jobs

  • CLR usage

  • Service Broker

  • Replication

  • Database Mail

  • SSIS dependencies

  • External applications

Workload characteristics

Understand:

  • CPU utilization

  • Memory requirements

  • IOPS

  • Throughput

  • Database size

  • Growth rate

  • Peak workload

  • Connection count

  • Batch processing

  • Reporting workload

  • OLTP workload

Availability requirements

Determine:

  • Required uptime

  • RPO

  • RTO

  • Disaster recovery requirements

  • Geographic recovery requirements

  • Planned maintenance requirements

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:

  • Discovery

  • Compatibility assessment

  • Performance baseline

  • Capacity planning

  • Architecture design

  • Security design

  • Backup and recovery planning

  • HA/DR design

  • Migration planning

  • Testing

  • Cutover

  • Post-migration optimization

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.