You want to move a SQL Server application to Azure. Three distinct target platforms are available: SQL Server on an Azure VM, Azure SQL Managed Instance, and Azure SQL Database.
The right choice depends on which features your application requires, which dependencies exist, and which operational tasks you want to take on yourself. Workload, availability, and cost-effectiveness are further factors.
Begin with two questions: What does our application require today? And what should improve through the change? The comparison below helps you organize the answers.
The three options at a glance
VMSQL Server on an Azure VM: shaping the instance and operating system yourself
On an Azure virtual machine, you run SQL Server with access to the operating system and the instance configuration. You choose a suitable SQL Server version and edition and shape, among other things, the disks, installation, and maintenance.
This is an option especially worth evaluating when your application is closely tied to its current server: through additional software, operating system access, or features that a managed service does not provide in the same form.
These configuration options come with operational tasks. Patching, backups, monitoring, and SQL high availability need a coordinated procedure. Azure offers features and automation for this; overall responsibility for your SQL Server configuration and its verification remains part of your operating model.
The key question: What degree of control do you need, and how will the environment be operated over the long term?
MIAzure SQL Managed Instance: many instance features as a managed service
Managed Instance offers a managed SQL service with numerous instance-wide features. These include SQL Server Agent and cross-database queries within the same instance. Microsoft operates the underlying platform and takes over key tasks such as engine patching and automated backups.
This makes Managed Instance an important candidate for existing applications with several interrelated databases or other instance dependencies. The features in use must still be checked individually. For jobs, file access, external connections, and administration workflows, there are differences compared with a SQL Server that you operate yourself.
You do not get administrative access to the underlying operating system. Existing scripts and operational assumptions should therefore be part of the migration review.
The key question: Which of your instance dependencies does Managed Instance support, and which need to be adapted?
DBAzure SQL Database: the database as a managed service
With Azure SQL Database, the focus is on the individual database or on a group of databases in an elastic pool. Microsoft operates the platform and provides features for backup, availability, and monitoring.
The application connects to a database service. The logical server created in Azure is used for management and access; it is not an instance that you can administer freely, as on a VM.
Within SQL Database there are several service tiers. Hyperscale separates compute, data storage, and the transaction log into distinct components and is designed for databases up to 128 TB; backups there are snapshot backups. Hyperscale is a service tier of SQL Database. It is not available for Managed Instance.
This platform is a candidate for applications whose required features fit the database model. Familiar instance assumptions deserve particularly careful review: SQL Server Agent is not available, and ordinary cross-database queries using three-part names cannot be carried over unchanged. For certain tasks there are other approaches, such as elastic jobs or elastic query. Their prerequisites and limits belong in the architecture review.
The key question: Can your application work with the database features offered, and which adaptations make sense for that?
- Your team: own configuration
- Microsoft platform operations
- Service boundary: Microsoft operates from here
Microsoft explains the fundamental operating model in the overview of the Azure SQL family.
Comparing features and operational tasks
The table shows reference points for the selection. Actual support also depends on version, edition, service model, and configuration.
| Question | SQL Server on an Azure VM | Azure SQL Managed Instance | Azure SQL Database |
|---|---|---|---|
| What do you manage? | Operating system, SQL instance, and databases within the chosen operating model | Instance and databases within the service boundaries | Databases and their configuration within the service boundaries |
| Administrative operating system access? | Yes | No | No |
| SQL Server Agent? | Available with a suitable SQL Server edition | Available, with documented differences | Not available; check other automation, such as elastic jobs |
| Cross-database queries? | Native instance features, depending on configuration and permissions | Native queries within the same instance | Familiar three-part-name queries not available; check separate approaches |
| Additional software or local files? | Possible within the VM and SQL configuration | No freely configurable local operating system environment | No freely configurable local operating system environment |
| Who patches the operating system and engine? | Your operations team, or the agreed automation or service arrangement | Microsoft for the platform; prepare applications for maintenance | Microsoft for the platform; prepare applications for maintenance |
| How are backups created? | Configure and operate the chosen SQL or Azure backup method | The platform runs automated backups | The platform runs automated backups |
| What remains to be clarified for recovery? | The complete procedure, files, access, targets, and tests | Retention, a suitable restore path, access, and tests | Retention, a suitable restore path, access, and tests |
| What should you consider for availability? | VM and SQL architecture, failure scenarios, and application response | Service configuration, additional failure protection, and application response | Service configuration, additional failure protection, and application response |
| What shapes the sizing? | VM, storage, disks, SQL configuration, and workload | Instance sizing, service tier, and combined database workload | Database or pool sizing, service tier, and workload |
SQL Server on an Azure VM: Patching and backups run through your operating model. Azure offers features and automation for this; your team or the agreed service arrangement carries them out and verifies them.
SQL Server on an Azure VM: Patching and backups run through your operating model. Azure offers features and automation for this; your team or the agreed service arrangement carries them out and verifies them.
Azure SQL Managed Instance: The platform patches and runs automated backups. You define retention, the restore path, access, and tests.
Azure SQL Database: For these tasks, the same applies as for Managed Instance: the platform patches and backs up; defining and testing remain with you. Differences lie in the features, such as the Agent.
| Task | Microsoft platform | Your team | Service provider, e.g., PSGwithin the agreed scope |
|---|---|---|---|
| Patch the operating system and engine | carries out engine patching by the platformFor VM: provides features and automation | defines prepare applications for maintenanceFor VM: carries out itself or through the agreed automation or service arrangement | to be defined in the engagement |
| Define retention | provides features for backupFor VM: – depends on the chosen method | defines suitable retentionFor VM: defines in the chosen backup method | to be defined in the engagement |
| Create backups | carries out automated backupsFor VM: provides Azure backup methods to choose from | – does not run the automated backups itselfFor VM: carries out configure and operate the chosen method | to be defined in the engagement |
| Test the restore | provides restore pathsFor VM: – depends on the chosen method | verifies choose the path, clarify access, testFor VM: verifies complete procedure with files, access, targets, and tests | to be defined in the engagement |
| Design queries | provides diagnostic and automation featuresFor VM: – not a platform task | carries out data model, queries, transactions, database calls | to be defined in the engagement |
| Handle application errors | – not a platform task | defines response to connection interruptions, verifies in testing | to be defined in the engagement |
- carries outdoes the work
- definesdecides and configures
- verifiestests and demonstrates
- providesoffers features
The official detailed limits are given in Microsoft’s features comparison for SQL Database and Managed Instance. Also check the differences linked there if a feature is decisive for your application. A single green table cell does not replace an application test.
- VMCheck edition, permissions, jobAgent available with a suitable SQL Server editioncheck
- MICheck steps and differencesAgent available, with documented differencescheck
- DBPlan other automationNo Agent; check, for example, elastic jobs with their own prerequisitesadapt
- VMCheck configuration and permissionsNative instance featurescheck
- MIAre both databases in the same instance?Native access there; examine external access separatelycheck
- DBCheck a separate approachNo familiar three-part names; for example, elastic query (currently listed as a preview in Microsoft’s feature comparison) with its own limits; clarify transaction requirementsadapt
Five questions for your target selection
1Which prerequisites are actually binding?
Create a short list of the features and dependencies in use. These include databases, jobs, logins, connections to other systems, and file access. For packaged software, ask about the vendor’s approval for the specific target.
Distinguish three cases here: the application strictly requires a feature; an existing operational process uses it; or the feature is installed but may not be needed at all. This distinction can change the latitude in choosing a target considerably.
2Where will the application and database run after the move?
An application in your own data center can reach a database in Azure. How well this works also depends on the database calls. Many small database calls executed one after another are sensitive to additional round-trip time.
Therefore map out the complete path of an important operation: user, application, database, and the interfaces involved. Also check network access, name resolution, and authentication. A successful connection test is only the beginning.
3Which workload must the target handle?
Consider typical daily load, peaks, and periodic processing. Both the total resources required and the effort of individual business transactions and their concurrency matter.
A low average CPU utilization does not rule out a critical bottleneck during an import or the daily close. Two environments offering the same number of vCores likewise do not guarantee identical response times. For the selection, measured values and a suitable test on the target are more informative.
4Which responsibilities should your team carry?
A managed service relieves you of platform work. Your data, access rules, queries, and application workflows still need ongoing care. Suitable recovery objectives and the response to connection interruptions must also be defined and tested.
Record which tasks Microsoft takes on, which your team carries, and where a service provider supports. This also makes it possible to assess the operational benefit of a platform.
5Which total costs belong in the comparison?
Compare target options that meet the same business and operational requirements. Consider the performance required, storage, availability, data transfer, and operating effort. Existing license rights and contract assumptions must be checked against the specific offer.
A price comparison with differently planned failure protection answers the cost-effectiveness question only incompletely. Document, therefore, which services and assumptions each option includes.
All five questions: twelve open checks for your shortlist.
All five questions: twelve open checks for your shortlist.
Question 1: Which prerequisites are actually binding?
Question 2: Where will the application and database run after the move?
Question 3: Which workload must the target handle?
Question 4: Which responsibilities should your team carry?
Question 5: Which total costs belong in the comparison?
NotesThese points shape your selection
- 1List the features and dependencies in use: databases, jobs, logins, connections, file access
- 1For each feature, distinguish: mandatory, used by an operational process, or merely installed
- 1Ask the vendor for approval for the specific target
- 2Map the path of an important operation: user, application, database, interfaces
- 2Check network access, name resolution, and authentication
- 3Consider daily load, peaks, and periodic processing, not just the average
- 3Gather measurements and test on the target
- 4Assign tasks: Microsoft, your team, service provider
- 4Define and test recovery objectives and the response to connection interruptions
- 5Compare only options with the same business and operational requirements
- 5Check license rights and contract assumptions against the specific offer
- 5Document services and assumptions per option
Result: candidates to evaluate and open questions. No automatic winner.
Three typical starting situations
The following situations are illustrative examples, not PSG customer references and not finished architecture recommendations.
-
A long-established application with additional local software
Candidate to evaluate Azure VM
still to clarify
- Disks, maintenance, availability
- For a managed service: additional software, files, vendor approval
-
Several databases with shared jobs
Candidate to evaluate Managed Instance
still to clarify
- Specific jobs, external access, administration procedures
- Combined workload and instance sizing
-
An application with clearly limited database requirements
Shortlist SQL Database
still to clarify
- Suitable performance model
- Elastic pool or serverless only if the workload profile fits
A long-established application with additional local software
An application uses SQL Server, additional software on the same machine, and a process that handles files on local paths. The vendor initially supports only a full SQL Server installation.
Here, the Azure VM is an obvious candidate to evaluate. For a managed service, additional software, files, and vendor approval would have to be clarified beforehand. Suitable disks, maintenance, and availability remain part of the VM comparison.
Several databases with shared jobs
A system consists of several databases. Procedures access other databases in the instance, and SQL Agent jobs coordinate processing. No local additional software is needed.
Managed Instance is an important candidate to evaluate here. What remains to be examined are the specific jobs, external access, and administration procedures in use. In addition, the combined workload of the databases must fit the chosen instance sizing.
An application with clearly limited database requirements
An application uses a single database and can run recurring tasks outside SQL Server Agent. Connections, permissions, and error handling can be designed to suit the service.
Here, Azure SQL Database belongs on the shortlist. Next comes the choice of a suitable performance model. Elastic pools or serverless can be interesting for certain workload profiles; their benefit must fit utilization, response time targets, and operational requirements.
Hyperscale, serverless, and elastic pools: what to check
Hyperscale is a service tier with its own architecture, not a separate platform. The same questions count for the selection as for any service tier: features, workload, availability, and cost. Two points belong in the evaluation in addition. If you move to Hyperscale from another service tier, you can, according to Microsoft, return to General Purpose (reverse migration) only within 45 days and under certain conditions. And several new capabilities that Microsoft introduced in September 2026, such as auto-pause for Hyperscale serverless and larger Hyperscale pools, are in preview as of 27 October 2026.
For existing provisioned Hyperscale databases, Microsoft gives December 2026 as the end of Azure Hybrid Benefit. This belongs in an ongoing cost review.
Serverless can adapt compute to the workload within configured limits. Where auto-pause is supported and enabled, a database may first have to resume after an idle period. This affects the first connections and operations. For an application with strict response time targets, this behavior is part of the evaluation.
Elastic pools give several databases a shared set of resources. For this, the workload profiles must fit together. In addition, consider which limits apply to the individual database and which to the pool.
Both models are concrete tools for suitable workload patterns. Check behavior and costs against your own usage. Microsoft describes prerequisites and limits in the serverless overview and in resource management in elastic pools. For Hyperscale: overview of the service tier, reverse migration from Hyperscale, and auto-pause.
Putting hybrid operation and Azure Arc in context
The platform decision may also be to leave the database at its current location for now, or to move only part of the environment. Interfaces, management tasks, and network paths then become especially important.
SQL Server enabled by Azure Arc connects existing SQL Servers outside Azure to Azure management services. This can include inventory and assessments. This connection does not change the server’s location. Arc is therefore covered in the section on management and hybrid environments; the hosting decision for the three Azure targets compared here remains a separate question.
From the Arc portal, Microsoft now also offers a migration workflow to Azure SQL Database; as of 27 October 2026 it is in preview and offline only. It supports assessment and data transfer; it does not replace checking dependencies, cutover, and acceptance.
Source: Microsoft’s overview of SQL Server enabled by Azure Arc and migration from Azure Arc. Other Arc products are not evaluated in this comparison. Which data is transferred when connecting to Azure must be clarified before adoption.
Before the production cutover: six things to prepare
- 01
Record the inventory and dependencies. Document databases, applications, jobs, access, and the teams involved. Obtain vendor approvals for the target.
- 02
Determine the baseline workload and objectives. Select representative time windows and relevant business transactions. Define response times, throughput, error rates, and recovery objectives.
- 03
Check compatibility and target configuration. An assessment provides pointers to required adaptations and suitable sizing. Compare these pointers with the features you actually need.
- 04
Run a test migration. Transfer data and the required objects and check the business workflows. Also test jobs, identities, interfaces, and error recovery.
- 05
Plan the cutover and the fallback path. Define responsibilities, write freeze, synchronization, approval, and abort criteria. Handle a fallback after new writes at the target separately.
- 06
Prepare acceptance and operations. Define which measurements and business checks will support the sign-off. Hand documentation, monitoring, and recovery over to operations.
Microsoft documents a migration workflow with assessment and target comparison in SSMS. Tools like these support planning. Responsibility for a suitable application solution and its acceptance remains with the project team.
Frequently asked questions
Is Managed Instance interchangeable with any SQL Server?
Managed Instance supports many familiar instance features. Differences in individual features and operating procedures must still be checked. A test with your application is especially important when external access, special jobs, or additional components are involved.
Can we carry over SQL Server Agent jobs to SQL Database?
SQL Database has no SQL Server Agent. First, clarify what a job does and which permissions and dependencies it needs. Suitable automation can then be chosen. Carrying a job over unchanged is not a general migration path.
With SQL Database, is all access to other databases ruled out?
The familiar native cross-database queries using three-part names are not available. For certain tasks there are separate approaches, such as elastic query, with their own limits. Check the specific access, including transaction requirements, instead of classifying an existing application as automatically compatible.
Does Microsoft also take over performance tuning of the application with PaaS?
The service takes over platform tasks and offers diagnostic and automation features. The data model, queries, transactions, and database calls of your application remain major influencing factors. Targeted analysis and optimization may still be needed there.
What should we do if we have already migrated and the application is slower?
First, narrow down an affected operation and time period. Then compare application response time, database work, and platform utilization. Our performance guide for the move to Azure leads you through the next steps.
Sources and as-of date
Product limits change over time. This page reflects the status of 27 October 2026; for a specific decision, check Microsoft’s information as it stands then. This page is not based on any measurements or migrations of our own in Azure. The illustrations are structural models or explicitly labeled teaching examples. They contain no measurements, prices, or ratings. Microsoft currently lists elastic query as a preview in its feature comparison.
Sources from Microsoft (documentation reviewed on 27 October 2026): Overview of the Azure SQL family · Features comparison for SQL Database and Managed Instance · Serverless overview · Resource management in elastic pools · Overview of the Hyperscale service tier · Reverse migration from Hyperscale · Auto-pause · SQL Server enabled by Azure Arc · Migration from Azure Arc · Migration workflow in SSMS
Turning requirements into a well-founded choice
For your shortlist, record the features required, the adaptations necessary, operational tasks, cost assumptions, and the evidence still missing. This turns a product preference into a decision that can be verified.
PSG supports you in developing this foundation and in preparing the move with your team. More about Azure SQL consulting and migration.