Azure Data Studio is retired: where SQL Server users go next

Azure Data Studio was retired on February 28, 2026. Microsoft announced the retirement in February 2025, and its official retirement page is blunt about what that means: no more updates, no more security fixes, no more maintenance. If it is still the thing you open every morning to talk to SQL Server or Azure SQL, you are now running an unpatched application that holds your connection strings and credentials.

This post is a practical look at where to go next. It is written by someone who builds a SQL client, so take the bias into account, but the goal is to help you pick the right tool for how you actually work, and for a lot of people the right answer is not SQLly.

What Microsoft recommends

Microsoft's own answer has two parts:

• Visual Studio Code with the MSSQL extension for day-to-day development. Your existing .sql scripts and SQL database projects open there without conversion, and the extension now carries Schema Compare, a Schema Designer, a Query Profiler built on Extended Events, DACPAC/BACPAC import and export, flat-file import, and Jupyter-based SQL notebooks.
• SQL Server Management Studio (SSMS) for SQL Server Agent jobs and full administration. Microsoft explicitly calls SSMS "the supported home" for Agent and classic admin work.

For the extensions people installed into Azure Data Studio for other engines, the story is uneven. PostgreSQL moves to the PostgreSQL extension for VS Code. At the time of writing, Microsoft's table still lists the MySQL replacement as "pending announcement".

Match the tool to the job you used Azure Data Studio for

Azure Data Studio was a lot of things to a lot of people: a cross-platform query editor, a notebook host, a place to run a database project, a lightweight admin console. The replacement depends on which of those you leaned on.

You live in database projects, DACPACs and CI/CD

Go to VS Code with the MSSQL and SQL Database Projects extensions. That is where Microsoft is investing, projects open unchanged, and nothing else on this list replaces the DACPAC build and deploy pipeline. SQLly does not build or deploy DACPACs or SQL projects, and it is not trying to.

You used notebooks for runbooks and troubleshooting

VS Code again. The MSSQL extension ships SQL notebooks, and your existing .ipynb files are Jupyter files that VS Code already understands.

You are on Windows and do a lot of administration

SSMS. It is free, it is first-party, it covers Agent, Integration Services, Analysis Services and Reporting Services, and it tends to support new SQL Server features first. We wrote a longer, honest comparison at SQLly vs SSMS, and the short version is that plenty of people run SSMS on the Windows box for platform chores and something else everywhere else.

You mainly write and run queries, on a Mac or Linux machine

This is the group that feels the retirement most. SSMS is Windows-only, and not everyone wants a code editor as their database client. Your realistic options are VS Code with the MSSQL extension, a general-purpose multi-database client such as DBeaver or DataGrip, or a dedicated native client such as SQLly. The rest of this post covers what moving to SQLly looks like, feature by feature, including the gaps.

Azure Data Studio features, and where they land in SQLly

SQLly is a native SQL client for macOS, with supported-beta builds for Windows and Linux. It speaks SQL Server's TDS protocol itself, so there is no ODBC driver to install, and SQL Server and Azure SQL Database both connect today. Here is how the Azure Data Studio pieces people ask about map across. The status words come from the docs, which label anything unfinished.

Two rows deserve a second look before you commit. Entra ID sign-in and Azure discovery work, but the docs still mark them in progress because some of the firewall-rule and multi-tenant edges are being smoothed. If your whole estate is Entra-only Azure SQL, try it against your tenant before you rely on it. The plan views are also marked in progress; SSMS remains the more complete plan viewer today.

Moving your work across

There is not much to migrate, which is one of the nice things about SQL clients. Your scripts are plain .sql files, and SQLly opens them as they are. A T-SQL script written for Azure Data Studio behaves the same way, including GO separators:

-- a script that ran in Azure Data Studio runs unchanged
USE Sales;
GO

SELECT TOP (50) o.OrderId, o.OrderDate, c.Name, o.Total
FROM dbo.Orders AS o
JOIN dbo.Customers AS c ON c.CustomerId = o.CustomerId
WHERE o.OrderDate >= DATEADD(DAY, -7, SYSUTCDATETIME())
ORDER BY o.Total DESC;
GO

Connections are the part you re-create. For each server, add a connection with the host, port and database you already use, and pick the authentication that matches: SQL logins work today, and Entra ID sign-in is the in-progress path described above. Passwords go to your operating system's keychain rather than a settings file.

While you are re-creating connections, take the chance to do something Azure Data Studio never made easy: tell the tool which connections are dangerous. SQLly lets you mark a connection as Production or Staging, and the environment brings safety with it. Production connections are read-only with a rollback wrap by default, and writing to them takes a timed unlock. If you want the details, this post on catching UPDATE and DELETE without WHERE walks through every layer.

Things that will feel different

• It is not an editor platform. Azure Data Studio was built on the VS Code shell and had an extension marketplace. SQLly is a single native app with the tools built in. If you depended on a specific third-party extension, check for an equivalent before you switch.
• Destructive tools script first. Agent job changes, backup and restore, killing a session: SQLly opens the exact SQL in a tab for you to read and run, rather than acting from a dialog. Some people love this and some find it one step too many.
• It is not free for everyone. Azure Data Studio cost nothing at any company size. SQLly has a free tier for hobbyists, and it is not available inside organizations with more than 100 employees; see pricing for the licenses.

A sensible way to decide

1. List what you actually opened Azure Data Studio for in the last month. Be honest; most people find it is "run queries against three servers".
2. If the list includes SQL projects, DACPACs or notebooks, install VS Code with the MSSQL extension first. It is free and it is Microsoft's supported path.
3. If the list is mostly querying and light administration, and especially if you are on a Mac or Linux, try a dedicated client for a week alongside it. SQLly's download needs no account.
4. Whatever you pick, uninstall Azure Data Studio once you have moved. Unpatched software that stores database credentials is not something to leave lying around.

We keep a more detailed, side-by-side look at the two tools at SQLly vs Azure Data Studio, and the full list of SQL Server tools in SQLly lives under Tools.