SQL Server Management Studio (SSMS) is the primary management tool for SQL Server and Azure SQL platforms. It is also the official download location and update path for SQL Server Management Studio going forward.
In recent releases, SSMS has changed significantly, not in how it looks, but in how it installs, updates, and enforces connection behaviour. It now updates frequently, uses the Visual Studio Installer, and applies stricter encryption defaults by design.
If you still think of SSMS as a tool you install once and forget about, modern versions will surprise you.
One side effect of these changes is stricter default encryption behaviour. If you upgrade SSMS and suddenly can’t connect, see SSMS Certificate Chain Not Trusted Error (Trust Server Certificate Fix).
This post explains how SSMS works today, what changed with modern SSMS releases, and how to manage it sensibly as a DBA without surprises or unnecessary churn.
👉 Download SQL Server Management Studio (SSMS):
https://learn.microsoft.com/sql/ssms/download-sql-server-management-studio-ssms
What Changed With Modern SSMS
SSMS is now:
- Installed and updated via the Visual Studio Installer
- Released on a frequent, in-place update cadence
- Available in Release and Preview channels
- Fully 64-bit
- Actively maintained and decoupled from SQL Server engine releases
Side-by-side installation has been supported for years. What changed is that Microsoft now actively encourages parallel Release and Preview installs as part of the supported workflow.
SSMS is no longer tied to SQL Server engine releases. It behaves like a continuously updated client application, and DBAs need to treat it as such.
Permissions and Prerequisites
Before installing or updating SSMS, keep these basics in mind:
- Installation and updates require local administrator permissions
- SSMS must be closed before an update can apply
- Updates are pulled from Microsoft unless you use an internal source (for example, SCCM)
- Windows will prompt for elevation if you’re running as a standard user
Nothing unusual here, but worth stating explicitly, especially on shared servers and jump hosts.
Installing SSMS (Visual Studio Installer Model)
Starting with modern SSMS releases, installation is handled through the Visual Studio Installer.
If you were used to the old standalone SSMS installer, this can feel unfamiliar at first. In practice, it’s mostly a wrapper change rather than a functional one.
You download a small bootstrapper, the installer opens automatically, and SSMS is installed and updated from there. Visual Studio itself is not required.
Once you’ve used it a few times, installs and updates tend to be more reliable than the older MSI-based SSMS releases.
If you regularly need to launch SSMS under a different Active Directory account, especially on shared servers or jump hosts, see Open SSMS as a Different Domain User, which covers both the GUI and command-line approaches and how this changes with newer SSMS versions.
First Launch Experience
After installation, SSMS behaves exactly as you’d expect. Launch it from the Start Menu and connect as normal.
There is no functional difference in how you connect to SQL Server, manage databases, or run queries. The biggest changes are behind the scenes.
On first launch, many SSMS users go straight to connecting to an existing SQL Server.
In newer SSMS versions, this is also where you may first encounter stricter encryption behaviour. If you see a certificate or SSL error at this stage, it’s usually a client-side change rather than a server problem.
👉 SSMS Certificate Chain Not Trusted Error (Trust Server Certificate Fix)
Running Multiple SSMS Versions Side by Side
You can safely install SSMS Release and SSMS Preview on the same machine. They update independently and do not interfere with each other.
This makes it easy to keep a stable Release build for day-to-day work while testing Preview features on your own terms. If you regularly manage multiple environments, keeping separate Release and Preview installs also reduces the risk of unexpected behaviour changes during critical work.
For example, stricter encryption defaults in newer versions are easier to test in Preview before rolling into daily use.
Older SSMS versions can still coexist as well, though if you still have a 2014-era SSMS install hanging around, it’s probably time to let it go.
Updating SSMS
SSMS updates frequently, and Microsoft expects it to stay current. How updates should be handled depends mainly on where SSMS is installed and how that machine is used.
Visual Studio Installer
Updating via the Visual Studio Installer is the most controlled approach.
You open the installer, locate the SSMS installation, apply the update if one is available, and restart if prompted. Updates only happen when you explicitly choose to apply them.
On jump servers, shared admin hosts, and other controlled environments, this avoids surprises and keeps client changes intentional.
Updating from Within SSMS
SSMS can surface update notifications when it launches. You may see a notification, an option to review details, or a prompt to apply an update on close.
You can also check manually via Help → Check for Updates.
This works well on personal workstations. On shared hosts, it’s easier to lose track of when and why the client changed.
Update on Close
SSMS can be configured to download updates automatically and apply them when the application closes. This setting applies per installation.
On personal machines, this can be convenient. On shared systems, including jump servers and incident response hosts, it introduces uncertainty about when client behaviour changes.
As a rule of thumb:
- Shared or controlled systems, update deliberately via the Visual Studio Installer.
- Personal workstations, in app updates are usually fine.
In environments where stability matters more than convenience, treat SSMS like any other client dependency, update intentionally, validate once, then standardise.
Update Channels
SSMS is released through two channels: Release and Preview.
Release is the stable, supported build intended for everyday DBA work. Preview provides early access to upcoming changes before they land in Release.
Each SSMS installation follows a single channel, and different installations on the same machine can use different channels if needed.
Switching channels installs the latest version available on that channel. It does not roll versions backwards.
For most DBAs, the sensible default is to run Release and forget about it.
Notable Improvements in Recent Releases
Rather than listing version numbers, these are the changes that actually matter day to day.
64-bit SSMS
SSMS is now fully 64-bit, which improves:
- Stability
- Memory handling
- Performance with large result sets
If you regularly work with large environments, this is a meaningful improvement.
UI and Usability Improvements
Recent versions introduced:
- Refined connection dialogs
- Better layout customisation
- Improved high-DPI handling
- Expanded theme support (dark mode & more)
To change your theme in SSMS, go to Tools at the top menu bar navigate to Themes. This can also be done within the Options menu within the Environments tab.
Git Integration and Copilot
SSMS now includes native Git integration and optional AI-assisted features via Copilot.
Whether you use them or not, they signal where Microsoft is taking the tooling. They are optional, not required, and easy to ignore if they do not fit your workflow.
Uninstalling SSMS
With modern SSMS releases (21+), the Visual Studio Installer is the supported way to uninstall SSMS.
To remove SSMS, open the Visual Studio Installer, locate SQL Server Management Studio, select More, and choose Uninstall.
The installer cleanly removes SSMS and all associated components.
Older methods such as removing SSMS via Add / Remove Programs (appwiz.cpl) only apply to legacy MSI-based versions. For current SSMS releases, the Visual Studio Installer owns the full install and uninstall lifecycle.
Final Thoughts
SSMS is no longer a static tool. It behaves like a regularly updated client application, and DBAs should treat it that way.
The important decisions are not about features, they are about:
- when updates apply
- which channel you follow
- where SSMS is installed
Once you understand the model, SSMS becomes easier to manage, not harder.
Leave a Reply