Azure SQL Database or Managed Instance

The migration plan looks simple until the first SQL Server Agent job appears. Azure SQL database or managed instance is a choice about how much instance behavior the application needs. Compare real dependencies before choosing the service tier.

Inventory the Application Contract

List databases, three-part names, SQL Server Agent jobs, linked servers, CLR use, Service Broker, and server-level logins. Include maintenance scripts and vendor software. The question is not whether a simple SELECT runs in both services. It is whether the whole application works without a rewrite you did not budget.

I ask for the busiest and the strangest stored procedures. Those reveal more than a generic compatibility checklist. A scheduled job that moves rows between databases can determine the destination even when most queries are ordinary. Capture current dependencies before changing connection strings.

Understand Azure SQL Database

Azure SQL Database is a managed database service with database-scoped administration. Microsoft handles underlying operating system work, engine patching, and automated backups. You still own schema, query performance, access, application retries, and service-tier selection. It fits applications that can live within a database boundary or use supported patterns for work beyond it.

Cross-database three-part queries from a traditional SQL Server instance do not simply carry over. Elastic query has a different setup and limitations. SQL Server Agent is not an instance feature inside a single Azure SQL Database. External scheduling services or application jobs can replace it, but that is a real design change.

Understand Managed Instance

Azure SQL Managed Instance keeps more familiar instance-level behavior. It supports SQL Server Agent and native cross-database queries within the managed instance. That makes migrations with several related databases less disruptive. It still differs from a self-managed SQL Server VM, so confirm each required feature and configuration option.

A managed instance has network and deployment choices that need planning. Its private connectivity model, subnet requirements, and application access differ from opening a single database endpoint. I validate the route from every application and administration tool before calling the migration easy.

Check Feature Evidence

Do not infer service type from a database name. On the current SQL Server, look for cross-database references in module definitions and catalog dependencies. This query gives one inventory slice. Dynamic SQL and external application code need separate review, so a blank result is not proof of independence.

I use the result to identify scripts for a compatibility test. A procedure that depends on another database deserves an actual execution in the target service.

SELECT OBJECT_SCHEMA_NAME(referencing_id) AS schema_name,
       OBJECT_NAME(referencing_id) AS module_name,
       referenced_database_name,
       referenced_schema_name,
       referenced_entity_name
FROM sys.sql_expression_dependencies
WHERE referenced_database_name IS NOT NULL
ORDER BY module_name;

Account for Agent and Scheduling

On Managed Instance, SQL Server Agent supports familiar job scheduling, subject to service differences. On Azure SQL Database, move recurring work to an external scheduler or application service. That includes imports, summary refreshes, cleanup, and alerts. A migration plan must show who owns retries, secrets, and failure notification after the move.

I inspect job steps, proxies, file paths, and linked servers rather than counting jobs alone. A job that invokes a local executable is not portable just because Agent exists. The tool can schedule it only if the environment and permissions support the actual step.

Compare Networking and Security in Azure SQL Database and Managed Instance

Check whether applications run in Azure, on premises, or across private networks. Firewalls, private endpoints, DNS, identity, and connection encryption all affect the design. Managed Instance networking has its own topology. Azure SQL Database offers several connectivity options. Confirm the exact access path and test latency from real clients.

Do not put broad public access in place just to make a pilot connect. I prefer a narrow test from the intended network and identity. A working connection from an administrator laptop proves little about the production application path.

Price the Whole Workload on Azure SQL Database or Managed Instance

Compare compute, storage, backup retention, high availability, and network costs for each option. Azure SQL Managed Instance can be a better compatibility fit while costing more for a small standalone database. Azure SQL Database has service tiers and pooling choices that can lower cost for independent databases. The correct comparison uses workload shape, not list price alone.

I also price the rewrite and operations. Removing cross-database joins or Agent jobs has a development cost. Running a managed service still requires monitoring and tuning. The cheapest monthly service line can be the more expensive migration.

Check Current Database Shape

This inventory shows database size and compatibility level on an existing SQL Server. It is only a starting point. Active working set, peak CPU, log rate, and query mix drive service sizing. Use a representative load test in the candidate tier before committing.

The output can reveal a fleet of tiny independent databases or a few large tightly coupled ones. That distinction matters more than the total file size.

SELECT name, compatibility_level,
       state_desc, recovery_model_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

SELECT DB_NAME(database_id) AS database_name,
       SUM(size) * 8.0 / 1024 AS allocated_mb
FROM sys.master_files
WHERE database_id > 4
GROUP BY database_id;

Prove the Fit of Azure SQL Database or Managed Instance With a Pilot

Move a representative database and run its important transactions, jobs, reports, and failure paths. Check the connection route, identity, query plans, and operational scripts. Include a rollback plan and a full restore test. One successful login is not a migration test.

Azure SQL database or managed instance should be chosen from application dependencies and measured workload. The familiar name is less important than the behavior the application needs. I keep the decision record short: required features, tested gaps, expected cost, and the owner of each change.

When a pilot passes the feature checklist, run the operational checklist too. Restore a backup into the chosen service, rotate a credential, test a scheduled task, and trace one slow query. Those exercises expose assumptions that a schema migration report cannot see. An application can connect and still depend on an Agent job nobody remembered.

I compare the total monthly operating shape, including storage, backup retention, networking, monitoring, and any companion services. The lowest advertised compute tier is not the price of a working system. Record the workload’s peak and quiet periods, then verify how the selected tier handles both. I want the choice to make sense at the next busy season, not only on a calm Tuesday.

Which application feature and operating task would fail first on the service you are considering? Write that answer beside the pilot result.

Related reading on this blog: SQL Azure Managed Instance Restore Error: The Database Was Backed Up on a Server Running Version 15.00.2000 and How to Create Linked Server to SQL Azure Database?.

A managed database choice is not a branding choice, it is a fit between application dependencies and service behavior.

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