A development team opens its usual SQL editor to troubleshoot a slow customer portal. The saved connections still work, and yesterday’s queries run normally. However, the tool is no longer receiving security fixes, and the team’s troubleshooting notebooks contain production results that should never have been committed to Git.
That is the situation organizations still using Azure Data Studio need to address. Microsoft retired it on February 28, 2026. Existing installations may continue to launch, but they no longer receive updates or security fixes. Microsoft recommends Visual Studio Code with the MSSQL extension for supported SQL development workflows.
This guide explains what Azure Data Studio provided, how to transition its workflows, and how to validate database access, security, performance, and operational readiness in the replacement environment.
What Was Azure Data Studio?
Azure Data Studio was a cross-platform desktop tool for querying and developing databases. It ran on Windows, macOS, and Linux and provided a SQL editor, connection management, result grids, notebooks, database projects, and extensions.
It was a client application—not a database engine, Azure hosting service, or replacement for a database administrator.
That distinction matters. Installing Azure Data Studio did not create an Azure subscription, provision a database, configure backups, or make an application highly available.
What teams used it for
Common workflows included:
- Writing and testing T-SQL, Microsoft’s SQL Server programming language.
- Querying SQL Server, Azure SQL Database, and Azure SQL Managed Instance.
- Saving diagnostic queries alongside documentation.
- Managing SQL database projects.
- Exporting selected results for analysis.
- Using extensions for specialized development tasks.
Azure Data Studio also appeared in many older Azure tutorials. Those instructions now need review rather than automatic reuse.
For background on the database platform itself, see the Azure SQL Database tutorial.
Pro Tip: I separate database-client decisions from database-platform decisions. Replacing an editor should not become an unnecessary database migration.
Azure Data Studio Retirement: What Changes Now?
The February 28, 2026 retirement means Azure Data Studio is no longer a supported tool receiving ongoing fixes. It does not mean your databases stopped working or that existing SQL scripts became invalid.
The immediate concern is the workstation software and the workflows built around it.
An outdated client can retain authentication metadata, cached information, extensions, and exported data. Continuing to use it indefinitely increases maintenance uncertainty even when its main query window still works.
What should move
Inventory these items before uninstalling anything:
| Item | Recommended action |
|---|---|
| SQL scripts | Open and test in the supported replacement |
| Saved connections | Import supported connection metadata |
| Connection groups | Preserve grouping and environment labels |
| SQL database projects | Open, build, and validate |
| Notebooks | Test kernels, execution, and output handling |
| Extensions | Identify a supported replacement for each required workflow |
| Exported results | Review retention and sensitive-data exposure |
Do not assume that every extension has a direct equivalent. The goal is to preserve required tasks, not recreate an old interface exactly.
Also review internal training materials. Remove instructions that recommend installing Azure Data Studio for a new workstation.
Pro Tip: I inventory workflows before inventorying extensions. A team may no longer need an extension, but it still needs a reliable way to complete its underlying task.
Choose the Right Azure Data Studio Replacement
For most SQL development work, start with Visual Studio Code and Microsoft’s MSSQL extension. For classic SQL Server administration, retain SQL Server Management Studio, commonly called SSMS.
Microsoft identifies VS Code as the SQL development transition path while keeping SSMS as the supported home for SQL Server Agent and general administration.
| Requirement | Practical starting point |
|---|---|
| Cross-platform SQL editing | VS Code with MSSQL |
| SQL scripts alongside application code | VS Code with MSSQL |
| SQL database projects | Supported SQL database project tooling |
| SQL Server Agent jobs | SSMS |
| Detailed SQL Server administration | SSMS |
| Repeatable database deployment | Reviewed deployment tools and pipelines |
| Azure resource configuration | Azure portal, CLI, PowerShell, or infrastructure as code |
A database project describes database objects as source-controlled files. It is different from a folder containing unrelated SQL scripts.
Do not confuse VS Code with Visual Studio. They are separate products, and instructions for extensions or project systems may differ.
Avoid unnecessary infrastructure
You do not need to create a resource group or deploy a new database just to replace Azure Data Studio.
An Azure subscription is a billing and governance boundary. A resource group is a management container for related Azure resources. Neither is a prerequisite for editing a local SQL file.
Use the existing approved database environment for migration testing, preferably a nonproduction database first.
Pro Tip: I keep SSMS available for administrative tasks instead of forcing every operation into one editor. Standardizing workflows is more useful than standardizing every task on one application.
Migrate Connections, Scripts, and Settings
Start with a controlled pilot workstation rather than changing every developer environment simultaneously.
Install supported tooling
Install the current approved VS Code release and Microsoft’s MSSQL extension. Verify the publisher before installing similarly named extensions.
If your organization manages software centrally, use its approved distribution process. Extension installation should follow the same security expectations as other developer tooling.
Import Azure Data Studio settings
The MSSQL extension includes an Azure Data Studio migration workflow:
- Open the Command Palette.
- Search for the Azure Data Studio migration command.
- Select or browse to the Azure Data Studio settings file.
- Choose connection groups, connections, and supported settings.
- Import the selected items.
- Apply the supported database-management keymap if required.
The documented importer brings across connection metadata, groups, and supported editor settings. Do not assume it transfers usable authentication secrets; plan to authenticate again and verify each connection.
Validate scripts and projects
Open existing .sql files directly. Queries and database projects do not require a blanket conversion simply because the editor changed.
However, validate project builds, dependencies, publishing settings, and extension requirements. File compatibility is not proof that the full deployment process works.
Keep project changes in a dedicated branch so the migration does not get mixed with unrelated schema changes.
The Azure Repos permissions guide helps define who can read and modify database source.
Pro Tip: I migrate one representative developer first: someone who uses queries, projects, notebooks, and production diagnostics. That pilot reveals gaps a basic connection test misses.
Secure Database Connections Before Reusing Them
A migrated connection is not automatically a secure connection.
Prefer Microsoft Entra ID authentication for supported Azure SQL environments. Entra ID provides identity authentication, including organizational controls such as multifactor authentication.
Azure RBAC governs access to Azure resources. SQL database permissions govern access to data and database objects. A person who can view an Azure SQL resource in the portal does not automatically have permission to query its tables.
Use separate operational identities
Use least privilege: grant only the access required for the task.
Keep application, reporting, deployment, and administration identities separate. Do not normalize connecting every editor as sa, a SQL Server system administrator, or an unrestricted database owner.
For applications and automation, prefer managed identities where supported. A managed identity is an Azure-managed identity that avoids an embedded password. It still needs an explicitly authorized database principal and permissions.
Interactive users should authenticate through approved user sign-in flows rather than borrowing an application identity.
Validate encryption
Transport Layer Security, or TLS, protects data in transit. Configure encrypted connections and validate the server certificate.
Avoid treating “trust server certificate” as a routine fix. It bypasses an important server-identity check.
An authorized administrator can inspect session encryption:
SELECT
session_id,
encrypt_option,
auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;This dynamic management view exposes connection details. @@SPID identifies the current session.
An encrypted result does not independently prove that the client validated the certificate. Review the client connection settings too. DMV permissions vary by database platform and version.
Store unavoidable secrets in Azure Key Vault rather than source files, spreadsheets, shared folders, or unprotected application settings.
Pro Tip: I test the replacement editor with a non-administrator database account. Administrative access can hide both missing grants and an unnecessarily br