What are the migration plans for non-Windows users after ADS goes?

[LarnuUK]

Several of the features in ADS have a replacement solution list as SSMS in the documentation.

Azure Data Studio extension	Description	Replacement
SQL Server Agent	Manage and automate SQL Server Agent jobs.	SQL Server Management Studio (SSMS)
SQL Server Profiler	Trace and monitor SQL Server activity.	SQL Server Management Studio (SSMS)
Database administration	Tools for managing databases on Windows.	SQL Server Management Studio (SSMS)
Schema	Compare and synchronize database schemas.	Visual Studio SQL Server Data Tools (SSDT). In development for MSSQL extension for VS Code.
Flat-file import	Import .txt and .csv files into databases.	Bulk insert / PowerShell. In development for MSSQL extension for Visual Studio Code.
DACPAC import/export	Deploy and extract DACPAC files.	SqlPackage / MSSQL extension for Visual Studio Code.
Azure SQL migration	Migrate SQL Server to Azure SQL.	Azure portal (future updates planned).
Notebooks	SQL + Markdown interactive documents.	Polyglot Notebooks in Visual Studio Code.
SQL Database Projects	Create, manage, and deploy SQL database projects.	Fully supported in the MSSQL extension for VS Code and Visual Studio.

SSMS is a Windows Only application so, for example, someone on using SSMS to manage Agent Jobs isn't an option. What is the Replacement tool for Agent, Profile, and Administration (yes, that very basic thing) for ADS users that aren't on Windows?

[kburtram]

@LarnuUK, thank you for raising this issue. We’re actively reviewing user feedback to define the core ADS functionality needed in VS Code to serve as a viable replacement for most use cases. Our goal is to focus VS Code on developer-centric database tasks, though we recognize the line between these and traditional administration tasks isn’t always clear-cut. Features like SQL Agent configuration or Central Management Servers lean more toward administrative roles, and we currently believe these are better suited to SSMS, where users may find greater success for those needs.

Other areas—like server/database properties, user management, and Profiler—fall into more of a gray zone. These could be considered foundational for VS Code, and we’re still evaluating based on user demand. Current thinking leans toward including properties and user management in the VS Code scope, while Profiler remains TBD. SQL Agent seems less likely to be ported, though nothing is set in stone. For now, potential workarounds include: (1) using a Windows machine with SSMS if feasible, (2) running a Windows VM via VirtualBox/Parallels, or (3) managing Agent jobs directly with T-SQL. We understand these may not be ideal for everyone and appreciate your patience as we refine this direction.

[LarnuUK]

That so much functionality is being lost leads me to just wonder why Microsoft therefore thinks that deprecating ADS is the right move. It almost feels more like it's a hidden attempt to get people to move to Windows from other operating systems if they use SQL Server. I almost wonder if this is an indication that Microsoft are also going to pull SQL Server on Linux support with SQL Server 2025...

[rjrjensen]

@kburtram I don't think it's a smart move to assume all developers don't also have administrative responsibilities.

I work for a company where I'm the main IT guy and I have to manage the SQL Server they have running every now and then. I have a MacBook currently, so Azure Data Studio is my main tool to manage some of the Agent Jobs that run every day. I had to change the schedule of one just today.

I saw the popup that said it was going away and merging into Visual Studio Code and I thought that could be cool since Azure Data Studio is the same thing under the hood and the extensions shouldn't be that hard to port over, but then my stomach sunk when I saw that the "recommended replacement" for SQL Server Agent is something I can't install on my machine.

With all the cross-platform pushes across the Microsoft ecosystem, it's very surprising that your team would announce this step backward. I really hope you guys take this into consideration and just work to port all the Azure Data Studio extensions over. Thank you for reading all of this, by the way!

[LarnuUK]

For now, potential workarounds include: (1) using a Windows machine with SSMS if feasible, (2) running a Windows VM via VirtualBox/Parallels, or (3) managing Agent jobs directly with T-SQL. We understand these may not be ideal for everyone and appreciate your patience as we refine this direction.

Honestly, 1 and 2 completely contradict my points; I'm talking about people who aren't in a Windows Environment; "Buy Windows" isn't the answer and should not be the answer. For 3, that "solution" is tedious and incomplete at best; Agent isn't the only thing I referenced.

If you want VSCode MSSQL to be aimed at Developers only then is it NOT a replacement for ADS (if I could emphasise that "not" more, I would). ADS provides far more than a developer solution, as has been evidenced, and is cross-platform; SSMS isn't a solution as it's not cross platform and MSSQL isn't a solution as it lacks functionality (by design?).

Stating this "may not be ideal" is an understatement; it outright breaks things. Having a slow puncture in your car tyre "isn't ideal", but you can inflate it so that you can get to a garage to get it repaired; having entire wheel structure fall off isn't "not ideal" it's now un-drivable without external recovery. Microsoft is doing the latter, not the former.

[kburtram]

@LarnuUK @rjrjensen Thanks for providing additional context on the impact and your expectations here. We aren't specifically dividing features into dev vs. admin buckets and using that as a criteria for whether to port to vscode. It's more about directionally which functionality makes sense in vscode and will be useful and relevant there. With the recognition that cross-plat Azure SQL/SQL Server users in vscode tend to have a developer-slant, though the boundaries aren't hard and this is really just one signal in the "how well does this feature fit" calculation (other criteria are things like adoption of the feature in ADS, general quality of the feature in ADS, availability of high quality alternative tooling, etc.).

I'm happy to try to share the current thinking around any particular feature. Please let me know if there's any area where I can add more context. I've focused primarily on agent since that's currently in the "not planned for vscode" bucket. Though I hear you that running SSMS in a VM doesn't sound like a reasonable "workaround". The deprecation is more about focusing limited engineering resources on aligning with the general direction of emphasis on vscode/github as primary cross-platform tooling offerings. And from a technical perspective, we now believe we can deliver a comparable or better experience in vscode as we can in ADS (which wasn't the case when the project was started), so the need to maintain a vscode fork is harder to justify.

There's still a 12-month window where ADS is fully supported. And we're still discussing every feature in ADS that isn't planned for the vscode port, and specifically looking at the proposed workarounds. We'll be publishing our 2025 roadmap on the vscode-mssql repo soon and that will be open for comments and discussion about any of the scoping decisions. It's our desire that all the ADS users land in a good place after this transition, and hopefully in a better place tool-wise all-up.

[Clifra-Jones]

@kburtram I have to agree with @LarnuUK, While the management features in ADS are still not mature, those that work are very useful. Many administrators/DBAs may be working on a non-Windows workstation. While that may not be the "optimal" platform from a Microsoft perspective, there are many valid reasons why this may be the case. Many people prefer the MAC and other Linux. Being required to deploy a VM, or a virtual desktop (such as AWS WorkSpaces) means deploying additional resources and costs just to manage SQL Server, and many of is who ware the DBA hat expressly forbid admins from RDPing into our SQL Servers.

While I am sure no one expects support for things like Integration and Analysis server. Being able to provision a User/Group, configure an Agent Job without jumping into a remote desktop or VM doesn't seem like such a large ask!

(Yes, these thing CAN be done with t-SQL, but how many SQL Server DBAs has that committed to memory. after 3 decades as a DBA, I don't)

There are many useful extension to RDS. As RDS and VS Code are both Electron application I assume that the extension framework isn't that different. If there were some documentation and procedure to convert an RDS extension to VS Code that would be very helpful to those folks who invested time (and money, because time is money) into ADS developing extension. Right now, I would think these folks feel particularly abandoned!

Lastly, having "one tool to rule them all" is very useful for those of us that work in a variety of databases. The fact ADS supports MSSQL, MySQL, PostgreSQL, etc. was a huge reason for adopting it over other tools! While VS Code can do this, it's not done well, IMO.

[kburtram]

@Clifra-Jones thanks for adding additional context. I hope my replies in no way suggest a lack of recognition that many users prefer non-Windows machines for various reasons. The ADS retirement announcement is not an attempt to push users to Windows machines. As part of the SQL Tooling team, we want you to be successful working with SQL on the platform of your choice.

Based on user feedback we have moved the User Management and Server/Database Properties experiences into set of features being ported to VS Code. The list of features not currently planned to be ported is relatively narrow, such as Agent and CMS, and these are areas that are actually done much better in SSMS than ADS. But if those features end up being a significant blocker for users to be able to successfully move forward, we'll be continuing reevaluating feedback on a feature-by-feature basis and make adjustments as needed.

Peer teams are actively working on improving extensions for Postgres and MySQL in vscode. We're working together to try to ensure alignment and consistency across the extensions, though they are different codebases so there will be some differences. If the quality isn't meeting your expectations on any of these experiences, please log github issues so we can track and address. Thanks!

[LarnuUK]

Thanks @kburtram , letting people know your, or Microsoft's, thinking is well received; I hope you can appreciate that the initial "knee-jerk" reaction is going to be "You're taking the tools I rely on away!".

The list of features not currently planned to be ported is relatively narrow, such as Agent and CMS, and these are areas that are actually done much better in SSMS than ADS.

I agree that they are feature incomplete in ADS, however, there is a huge difference between incomplete and missing; it is being proposed those features are completely removed from the tool, along side Profiler, and (again) the "work-around" suggested is use Windows, which defeats the whole point of what ADS was/is.

Perhaps it would be an idea for a separate extension, for what Microsoft calls "Administrative Tasks" (honestly, I really don't see CMS as "DBA") should also be developed that depends on vscode-mssql, but not the reverse? Then users who use ADS for it's goals can use that extension, and vscode-mssql, while those using just vscode-mssql already don't get the bloat that the migrating ADS users need.