Masz otwarty projekt .NET i osobne okno z zapytaniem do bazy, które działa tak samo na Windowsie, macOS i Linuksie. Azure Data Studio nadal może uruchamiać się na komputerze, jeśli instalacja i środowisko na to pozwalają, ale od zakończenia wsparcia nie dostaje już poprawek bezpieczeństwa.
Wybór następcy zależy od zadań, które wykonujesz w bazie
- Dalsza praca: pliki SQL i projekty baz danych można otwierać w VS Code.
- Codzienne zapytania: rozszerzenie MSSQL obsługuje typową pracę z SQL Server i Azure SQL.
- Administracja: SQL Server Agent i pełniejsze zadania DBA wymagają osobnego narzędzia.
- Inne silniki: PostgreSQL, MySQL i Cosmos DB potrzebują własnych ścieżek migracji.
Od 28 lutego 2026 Azure Data Studio działa bez wsparcia
To data, która zmienia decyzję o używaniu programu na co dzień. Microsoft Learn podaje, że produkt został wycofany i nie otrzymuje już aktualizacji ani poprawek bezpieczeństwa; dotyczy to także osób, u których aplikacja nadal poprawnie się uruchamia.
Nie oznacza to, że lokalne pliki nagle znikają albo że zapisane zapytania przestają być tekstem SQL. Ryzyko dotyczy dalszego polegania na nieutrzymywanym środowisku, szczególnie gdy program jest częścią regularnej pracy zespołu lub łączy się z bazami firmowymi. W takim układzie plan przejścia powinien obejmować również poświadczenia, ustawienia i używane rozszerzenia.
Sam produkt był lekkim, wieloplatformowym środowiskiem dla SQL Server i usług Azure, z edytorem zapytań, notebookami oraz dodatkami. Ta wygoda tłumaczy, czemu część osób źle ocenia zastąpienie go zestawem rozszerzeń; inni wolą skupić narzędzia developerskie w VS Code. Rozbieżność opinii zwykle dotyczy płynności pracy i brakujących funkcji, a nie tego, czy zapisane pliki da się przenieść.
VS Code wystarcza do T-SQL, lecz zadania DBA zmieniają wybór
Jedno okno edytora i znajomy skrót do uruchomienia zapytania brzmią jak prosta zamiana. W praktyce rozszerzenie MSSQL dla Visual Studio Code pokrywa codzienne pisanie i wykonywanie T-SQL, pracę z projektami SQL oraz wybrane operacje na bazie, ale nie każda funkcja dawnego środowiska trafia do tego samego miejsca.
| Sytuacja | Co z tego wynika | Co zrobić |
|---|---|---|
| Zapytania, skrypty i projekt SQL | Pliki można otworzyć w VS Code bez konwersji. | Zainstalować rozszerzenie MSSQL i sprawdzić połączenie z bazą. |
| SQL Server Agent lub rozbudowana administracja | Rozszerzenie nie zastępuje pełnego zestawu narzędzi DBA. | Do zadań agenta i pełniejszej administracji użyć SSMS. |
| Notebook SQL dla procedury lub analizy | Notebooki SQL działają w VS Code, ale pojedynczy notebook łączy się z jedną instancją serwera naraz. | Przy pracy na wielu serwerach przygotować osobne notebooki albo przełączyć profil połączenia. |
| Wirtualizacja danych z dawnego dodatku | Nie ma bezpośredniego odpowiednika w rozszerzeniu MSSQL. | Przed migracją sprawdzić, czy potrzebę obsłuży PolyBase lub funkcja po stronie usługi. |
Ta tabela daje prostą regułę: jeśli większość dnia zajmują zapytania i projekty SQL, zacznij od VS Code z MSSQL; jeśli pracujesz z SQL Server Agent albo zadaniami DBA, zostaw SSMS w zestawie. Gdy używany dodatek nie ma odpowiednika, najpierw odtwórz konkretny proces, a dopiero potem wybieraj zamiennik. Sama nazwa rozszerzenia nie gwarantuje zgodności funkcji.
Typowy projekt .NET można przenieść bez przebudowy plików SQL
Wyobraź sobie repozytorium aplikacji z katalogiem projektu bazy, skryptami wdrożeniowymi i kilkoma zapisanymi połączeniami. Pliki projektu i zapytania można otworzyć w VS Code bez konwersji, więc nie trzeba przepisywać ich tylko dlatego, że zmienia się edytor. Do tego dochodzi MSSQL Migration Toolkit, który według materiałów Microsoftu pomaga przenieść obsługiwane połączenia, grupy, ustawienia i skróty.
Nie zakładałbym jednak, że migracja ustawień odtwarza całe środowisko. Zrób próbę na kopii ustawień, otwórz jeden projekt, wykonaj nieszkodliwe zapytanie i porównaj listę rozszerzeń z funkcjami, których zespół naprawdę używa. Szczególnej uwagi wymagają sekrety zapisane poza plikami projektu oraz ustawienia połączeń zależne od metody uwierzytelniania.
Przy takim sprawdzianie szybko wychodzi, czy problemem jest sam kod, czy otoczka narzędzia. Pliki SQL zwykle są najłatwiejszą częścią przeprowadzki; czas pochłania odtworzenie połączeń, nawyków i brakujących dodatków.
PostgreSQL, MySQL i Cosmos DB wymagają innych zamienników
Jeśli w jednym oknie obsługujesz kilka silników, migracja do samego MSSQL nie zamknie tematu. W oficjalnym zestawieniu Microsoftu dla PostgreSQL wskazano rozszerzenie PostgreSQL do VS Code, a dla Cosmos DB z API MongoDB rozszerzenie Azure Databases. Dla MySQL dokumentacja nie wskazuje równoważnego gotowego dodatku, więc ten przepływ trzeba ocenić osobno.
To rozróżnienie oszczędza fałszywych oczekiwań: rozszerzenie MSSQL jest przeznaczone przede wszystkim do SQL Server, Azure SQL i SQL Database w Fabric, a jego nazwa nie oznacza uniwersalnego klienta do wszystkich baz. Przy PostgreSQL lub MySQL sprawdź, czy potrzebujesz głównie edytora zapytań, przeglądania schematu, czy też narzędzi administracyjnych. Dopiero od tego zależy sensowny zamiennik.
Przenieś najpierw jeden przepływ pracy, nie całe środowisko naraz
Najmniej bolesna migracja zaczyna się od jednego reprezentatywnego zadania: na przykład uruchomienia skryptu wdrożeniowego z projektu .NET, a nie od odtworzenia każdego panelu i skrótu. Gdybym dobierał narzędzia dla zespołu, zostawiłbym VS Code z MSSQL do pracy developerskiej, a SSMS dodał tam, gdzie faktycznie potrzebna jest administracja SQL Server.
Po udanym sprawdzeniu połączenia przenieś pozostałe projekty i dopiero wtedy zdecyduj, co zrobić z dodatkami bez bezpośredniego odpowiednika. Taki porządek pozwala odróżnić zwykłą zmianę edytora od procesu, który wymaga osobnego narzędzia.
