Moving a SQL Server workload to Azure is not simply a backup-and-restore exercise.

Before migration, DBAs need to understand the existing environment, identify compatibility issues, measure workload performance, and determine which Azure SQL platform best fits the workload.

A structured assessment helps reduce migration risks and unexpected issues during cutover.

1. Start With Discovery

The first step is to understand what currently exists.

Collect information about:

A basic SQL Server inventory query can provide an initial baseline:

SELECT
    SERVERPROPERTY('ServerName') AS ServerName,
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductLevel') AS ProductLevel,
    SERVERPROPERTY('Edition') AS Edition,
    SERVERPROPERTY('EngineEdition') AS EngineEdition;

This should be combined with a broader discovery process rather than relying on a single query.

2. Understand Database Size and Growth

Database size is important for migration planning, but growth rate is equally important.

For example:

SELECT
    DB_NAME(database_id) AS DatabaseName,
    SUM(size) * 8.0 / 1024 AS SizeMB
FROM sys.master_files
GROUP BY database_id
ORDER BY SizeMB DESC;

You should also capture historical growth.

A database that is currently 500 GB but growing by 100 GB every month has very different capacity requirements from a database that has remained stable at 500 GB for several years.

3. Identify SQL Server Features

One of the most important assessment activities is identifying SQL Server features used by the application.

Examples include:

The question is not simply:

"Does the database work?"

The question is:

"Does the complete application ecosystem work on the selected Azure platform?"

This distinction is critical.

4. Check Compatibility

Compatibility analysis identifies database objects or features that may require modification.

Potential issues can include:

Unsupported Feature
       ↓
Application Dependency
       ↓
Required Code Change
       ↓
Testing
       ↓
Migration

For example, an application may depend on a SQL Server feature that is available on SQL Server but behaves differently or is unavailable on the selected Azure SQL service.

Therefore, compatibility should be assessed before selecting the final migration target.

5. Analyze SQL Agent Jobs

SQL Agent jobs are often overlooked during migration.

Inventory:

For example:

SELECT
    name,
    enabled,
    description
FROM msdb.dbo.sysjobs
ORDER BY name;

A job may contain references to:

These dependencies need to be redesigned or migrated appropriately.

6. Review Linked Servers

Linked servers are another important migration dependency.

Check them with:

SELECT
    name,
    product,
    provider,
    data_source
FROM sys.servers
WHERE is_linked = 1;

For every linked server, document:

Source
  ↓
Linked Server
  ↓
Target
  ↓
Application / Job Dependency

A linked server connecting to another SQL Server may require a different architecture after migration.

7. Establish a Performance Baseline

Do not migrate a workload without understanding its current performance.

Capture:

The baseline becomes the reference point for post-migration validation.

For example:

Before Migration
----------------
CPU       : 65%
IOPS      : 4,500
Latency   : 8 ms
Connections: 320

After migration, compare the same workload characteristics.

8. Identify Top SQL Queries

Query performance can change after migration because the underlying compute, storage, compatibility level, indexes, statistics, and execution plans may differ.

A DBA should identify expensive queries before migration.

Typical candidates include queries with high:

The objective is not necessarily to tune every query before migration.

Instead, identify the critical workload baseline so that any regression can be detected after migration.

9. Analyze High Availability and Disaster Recovery

Migration planning must include business continuity requirements.

Document:

RPO — Recovery Point Objective

How much data can the business afford to lose?

RTO — Recovery Time Objective

How quickly must the application be restored?

For example:

Business Requirement
        |
        +---- RPO
        |
        +---- RTO
        |
        v
Azure HA/DR Architecture

Azure SQL capabilities should then be mapped against these requirements.

10. Security Assessment

Security requirements should be assessed before migration.

Review:

A modern Azure SQL architecture commonly incorporates Microsoft Entra authentication and private network connectivity where appropriate.

11. Estimate Azure Cost

Migration decisions should include a realistic cost assessment.

Consider:

Compute
+
Storage
+
Backup
+
Networking
+
HA/DR
+
Monitoring
+
Licensing

Avoid estimating cost using database size alone.

Two databases of identical size can have very different Azure costs because their CPU, memory, I/O, availability, and workload requirements can be completely different.

12. Build a Migration Readiness Report

After assessment, create a migration report.

A useful format is:

Assessment AreaFindingRiskAction
SQL VersionLegacy versionMediumReview upgrade path
Linked Servers4 configuredHighValidate target architecture
SQL Agent25 jobsMediumReview job migration
Database Size850 GBLowValidate storage
PerformanceHigh CPU workloadHighEstablish baseline
HA/DRExisting AGMediumDesign Azure equivalent
SecurityMixed authenticationMediumReview identity model

This gives stakeholders a clear picture of the migration readiness.

13. Migration Decision

Once the assessment is complete, map the workload to the appropriate Azure target.

SQL Server Workload
        |
        v
Compatibility Assessment
        |
        +--------------------+
        |                    |
        v                    v
High PaaS Compatibility   Strong SQL Server Dependency
        |                    |
        v                    v
Azure SQL Database      Managed Instance / Azure VM

The final decision should consider technical requirements, operational responsibility, security, performance, availability, and cost.

14. A Practical Migration Checklist

Before production migration, confirm:

Conclusion

A successful Azure SQL migration starts long before the production cutover.

The most important step is assessment.

By understanding SQL Server dependencies, compatibility, workload performance, security, availability, and cost requirements, DBAs can select the right Azure architecture and reduce migration risk.

The migration should ultimately follow this principle:

Assess → Design → Test → Migrate → Validate → Optimize