Azure SQL Database and SQL Server: What Changes

Azure SQL Database keeps much of the SQL language familiar while changing who manages the platform. A successful move starts with identifying the instance-level assumptions hidden inside the application and its maintenance routines.

Separate the Three Deployment Choices

SQL Server on a virtual machine remains an instance you administer. Azure SQL Database is a managed database service. Azure SQL Managed Instance provides a different managed option with broader instance compatibility.

Do not combine these products into one cloud feature list. A capability supported by Managed Instance may be unavailable in SQL Database. Select documentation for the actual destination before changing a deployment script.

SELECT DB_NAME() AS current_database,
       SERVERPROPERTY('EngineEdition') AS engine_edition,
       SERVERPROPERTY('Edition') AS edition;
SELECT name, compatibility_level
FROM sys.databases
WHERE name = DB_NAME();

This query runs on SQL Server and Azure SQL Database. Interpret EngineEdition using the documented values rather than a guess from the display name. Record compatibility separately from the service or engine version.

Move Scheduled Work Deliberately

Azure SQL Database does not include SQL Server Agent. Existing Agent jobs need an explicit destination, such as Azure SQL elastic jobs or another suitable scheduler. Managed Instance includes Agent, subject to documented differences.

Inventory each step rather than copying only the schedule. A job may invoke an executable, access a Windows share, or depend on a local service account. Those dependencies matter more than the job's name.

-- Run on the source SQL Server instance.
SELECT j.name AS job_name, s.step_id, s.step_name,
       s.subsystem, s.database_name
FROM msdb.dbo.sysjobs AS j
JOIN msdb.dbo.sysjobsteps AS s ON s.job_id = j.job_id
ORDER BY j.name, s.step_id;

Decide who owns retries, credentials, failure notifications, and overlapping executions in the replacement. Test a failed run and a missed run. A migrated schedule is incomplete until its operational behavior is understood.

Find Cross-Database Assumptions

Ordinary three-part cross-database queries do not transfer directly to Azure SQL Database. Elastic query offers specific remote-query capabilities, with documented preview status and limitations. It is not a transparent replacement for every instance-level pattern.

Search procedures, views, synonyms, application queries, and scheduled steps. Dependency metadata is a useful starting point, but dynamic SQL can escape it. Capture actual workload paths as part of the review.

SELECT OBJECT_SCHEMA_NAME(referencing_id) AS schema_name,
       OBJECT_NAME(referencing_id) AS object_name,
       referenced_server_name, referenced_database_name,
       referenced_schema_name, referenced_entity_name
FROM sys.sql_expression_dependencies
WHERE referenced_database_name IS NOT NULL
   OR referenced_server_name IS NOT NULL;

This inventory query can run against the source database. Review transaction boundaries as well as SELECT statements. Splitting a transaction across service boundaries is a design decision, not a spelling change.

Keep Familiar Monitoring With the Right Scope

Many familiar catalog views and DMVs remain available under the same names. Their scope, columns, and required permissions may differ. There are also service-specific views for resource consumption and platform behavior.

-- Run in the target Azure SQL Database.
SELECT TOP (20) end_time, avg_cpu_percent,
       avg_data_io_percent, avg_log_write_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

This Azure-specific query is not intended for a local SQL Server instance. Interpret its percentages against the database's resource limits. A service limit can matter even when an old server-based monitoring query looks quiet.

Keep Query Store and application latency evidence in the monitoring plan. Track connection failures and retries alongside query performance. Managed infrastructure still needs a measured workload baseline.

Understand the Backup Boundary

The service performs automated backups instead of accepting your normal BACKUP DATABASE schedule. You still make retention and recovery decisions within supported options. Review point-in-time recovery, long-term retention, and backup storage redundancy.

Do not describe this as having no control over backups. The control moves from individual backup commands to service policies and restore operations. Confirm that those policies meet the application's recovery requirements.

Test restoring a separate database and reconnecting an application copy. Measure the complete recovery process, including access and configuration. A retained backup alone does not prove the required recovery time.

Change the Operating Routine

The platform handles underlying infrastructure and engine maintenance that previously required your own administration. You still own schema design, query behavior, data access, and application correctness. Capacity and cost require ongoing attention.

Review authentication, network access, connection strings, and transient-error handling before the move. Use the supported identity model for the selected service. Avoid assuming that a Windows service account transfers unchanged.

Build a migration checklist from the actual dependencies you find. Test representative writes, reports, maintenance replacements, and recovery. Choose the deployment model that meets those requirements with a manageable operating burden.

A managed database is not the end of database administration, it is a different division of responsibility.

This post was rewritten from scratch in September 2026. The original, published on 2010-05-25, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.