Azure Data Studio Retirement: What to Use Instead

September 2, 2026 by Chat2DB

Microsoft announced in 2025 that Azure Data Studio would be retired, and support ended on 28 February 2026. The official recommendation is the MSSQL extension for Visual Studio Code. If you were using Azure Data Studio as a lightweight query editor for SQL Server, that path is straightforward. If you were using it as your main database client — notebooks, dashboards, several engines, data import and export — the extension is not a like-for-like replacement, and it is worth planning the move rather than discovering the gaps one at a time.

This guide covers what actually stops working, what the alternatives cover, and how to get your connections and notebooks out.

What the retirement means in practice

Retirement is not a remote kill switch. An installed copy of Azure Data Studio continues to launch and connect. What ends is everything around it:

No further releases, including security patches for the Electron and Node runtime underneath.
No support cases. Microsoft support will ask you to reproduce the issue in a supported client.
No extension marketplace guarantees. Extensions that depend on the ADS API stop being updated, and marketplace availability is not promised indefinitely.
No compatibility work against new server features. As SQL Server and Azure SQL evolve, object types the client does not understand simply do not appear in the object explorer.

That last point is the one that bites over a longer horizon. A client that is no longer updated gradually diverges from the server it manages.

The security angle is the more urgent one for regulated environments. An Electron application that no longer receives Chromium security updates is difficult to justify in a compliance review, regardless of how well it still works.

What the VS Code MSSQL extension does and does not cover

The MSSQL extension for Visual Studio Code has improved substantially, and Microsoft has moved several Azure Data Studio features into it. It covers:

Connection management with saved profiles, including Microsoft Entra ID authentication and Azure SQL connection browsing.
A query editor with IntelliSense, a results grid and export to CSV, JSON and Excel.
An object explorer for the common object types, with scripting.
A schema designer and query plan visualisation in recent releases.
Full integration with the rest of VS Code — source control, terminals, the extension ecosystem.

What is different from Azure Data Studio:

Notebooks. ADS SQL notebooks (.ipynb with a SQL kernel) are not a first-class feature of the extension. The nearest equivalents are running SQL through a Jupyter kernel with a Python driver, or using a client that has notebook-style multi-result sessions.
Dashboards and widgets. The ADS server and database dashboards with insight widgets have no direct counterpart.
Only SQL Server. ADS had community extensions for PostgreSQL and other engines. The MSSQL extension does one family: SQL Server, Azure SQL, and Fabric SQL databases.
A different mental model. VS Code is an editor with a database extension. If your team includes DBAs and analysts who do not otherwise use an IDE, this is a real adoption cost.

If your usage was "connect, write T-SQL, look at a grid", the extension is fine and you should just move. Read on if it was not.

Exporting your connections

Do this before uninstalling anything. Azure Data Studio stores connection profiles in its settings file:

Windows: %APPDATA%\azuredatastudio\User\settings.json
macOS: ~/Library/Application Support/azuredatastudio/User/settings.json
Linux: ~/.config/azuredatastudio/User/settings.json

The relevant key is datasource.connections. Passwords are not in that file — they are in the OS credential store (Windows Credential Manager, macOS Keychain, or libsecret) — so you will re-enter them wherever you land.

Pull out a readable list first:

# macOS / Linux
python3 - <<'PY'
import json, os
p = os.path.expanduser("~/Library/Application Support/azuredatastudio/User/settings.json")
with open(p) as f:
    cfg = json.load(f)
for c in cfg.get("datasource.connections", []):
    o = c.get("options", {})
    print(f"{c.get('groupId','')}\t{o.get('server')}\t{o.get('database','')}\t{o.get('authenticationType')}\t{o.get('user','')}")
PY

Keep that output. It is the checklist for rebuilding connections in whatever client you choose, and it is also the audit trail for which servers a departing team member had configured.

For VS Code, the MSSQL extension keeps its profiles under mssql.connections in VS Code's own settings.json, and the option names largely match, so a scripted conversion is realistic:

import json, os
 
ads = os.path.expanduser("~/Library/Application Support/azuredatastudio/User/settings.json")
code = os.path.expanduser("~/Library/Application Support/Code/User/settings.json")
 
with open(ads) as f:
    src = json.load(f)
 
profiles = []
for c in src.get("datasource.connections", []):
    o = c.get("options", {})
    profiles.append({
        "server": o.get("server"),
        "database": o.get("database", ""),
        "authenticationType": o.get("authenticationType", "SqlLogin"),
        "user": o.get("user", ""),
        "profileName": o.get("connectionName") or o.get("server"),
        "savePassword": True,
        "encrypt": o.get("encrypt", "Mandatory"),
        "trustServerCertificate": o.get("trustServerCertificate", False),
    })
 
with open(code) as f:
    dst = json.load(f)
dst.setdefault("mssql.connections", []).extend(profiles)
with open(code, "w") as f:
    json.dump(dst, f, indent=2)
 
print(f"migrated {len(profiles)} connections")

Close VS Code before running that, and keep a copy of the original settings.json.

Rescuing notebooks

ADS SQL notebooks are ordinary .ipynb files with a SQL kernel. The cells and their outputs are portable JSON; what does not carry over is the kernel binding.

To convert a SQL notebook into plain .sql scripts:

import json, sys, pathlib
 
nb = json.loads(pathlib.Path(sys.argv[1]).read_text())
out = []
for cell in nb["cells"]:
    src = "".join(cell["source"])
    if cell["cell_type"] == "markdown":
        out.append("\n".join("-- " + line for line in src.splitlines()))
    else:
        out.append(src.rstrip() + "\nGO\n")
pathlib.Path(sys.argv[1]).with_suffix(".sql").write_text("\n\n".join(out))

That preserves the narrative as comments and the queries as runnable batches. For notebooks that genuinely need to stay notebooks — scheduled reports, runbooks with output — moving them to Jupyter with pyodbc or pymssql keeps the format and gains you a supported kernel:

# In a Jupyter cell
import pyodbc, pandas as pd
 
conn = pyodbc.connect(
    "DRIVER={ODBC Driver 18 for SQL Server};"
    "SERVER=tcp:sql01.internal,1433;DATABASE=appdb;"
    "UID=reporting;PWD=...;Encrypt=yes;TrustServerCertificate=no"
)
pd.read_sql("""
    SELECT TOP (20) name, create_date
    FROM sys.databases
    ORDER BY create_date DESC
""", conn)

Choosing a replacement client

Three shapes of answer, depending on what you were using ADS for.

You only touch SQL Server and you live in VS Code. Install the MSSQL extension and move on. It is the path Microsoft supports and it is free.

You manage SQL Server alongside PostgreSQL, MySQL, MongoDB or Redis. You want a general database client, which is what most ADS users with a mixed estate actually needed. Chat2DB (opens in a new tab) is the closest fit here: it runs on Windows, macOS and Linux, connects to SQL Server over TDS along with 20+ other engines, and its AI writes and explains T-SQL against your real schema — which covers a lot of what people used ADS notebooks for. There is a browser version at app.chat2db.ai (opens in a new tab) if you want to try it without installing. DBeaver is the strongest free alternative, DataGrip is the choice inside a JetBrains subscription, and TablePlus is the fastest native option on a Mac.

You are a Windows DBA doing administration, not queries. SSMS remains supported and Microsoft continues to ship it. Maintenance plans, Always On wizards and Integration Services tooling still only exist there. Many teams keep one SSMS install on a jump box for those jobs and use a cross-platform client for daily work.

A migration plan

Inventory. Export datasource.connections from every machine that has ADS. You will find servers nobody documented.
Classify usage. Ask the team what they actually did in ADS: queries only, notebooks, dashboards, imports. The answer decides the replacement.
Pilot with one team for two weeks. Do not roll out a client to fifty people based on a screenshot.
Convert notebooks to .sql scripts or Jupyter, and put them in source control while you are there. Most ADS notebooks were never versioned.
Rebuild connections in the new client, and take the opportunity to remove TrustServerCertificate=true where it was papering over a certificate problem.
Uninstall ADS from managed machines once the pilot team confirms nothing is missing, and remove it from your software allow-list so it does not reappear.

Summary

Azure Data Studio stopped being supported on 28 February 2026. Installed copies keep working, but there are no more security patches, no support and no compatibility work against newer server versions — which makes it hard to keep in a regulated environment. The VS Code MSSQL extension is the supported path if SQL Server is all you touch and VS Code is where you work. If you used ADS as a general database client, a cross-platform client such as Chat2DB, DBeaver, DataGrip or TablePlus covers more of what you lose. Export datasource.connections and convert your notebooks before you uninstall anything — both are easy while ADS is still on the machine and tedious afterwards.

Azure Data Studio on Mac: Status and Alternatives Azure Data Studio vs SSMS: Which One in 2026?