Bringing Back the Blue Theme SSMS 22 Dropped

What happened to Blue

If you've been writing T-SQL for a while, you know the one. Navy tab channel, gold selected tab, slate tool window headers. It was there in SSMS 18. It was there in 19, 20, and 21. Then SSMS 22 arrived and the Blue option was gone. The 22.0.0 release notes record it in a single table row: "Introduced new themes and removed the Blue (SSMS) theme."

Microsoft said why, and it's worth quoting properly rather than paraphrasing into a grievance:

There's a second reason underneath that one. SSMS 21 was built on the Visual Studio 2022 shell; SSMS 22 moved up to Visual Studio 2026, which Microsoft's SSMS FAQ states plainly — "Updated to Visual Studio 2026: SSMS is based on the latest Visual Studio release." That shell rebuilt how it colors itself from the ground up. Old Blue was written against the old system. The file is still perfectly valid. It just stopped meaning what it used to mean.

All of which is sound engineering, and cold comfort on a Monday morning when your muscle memory is looking for a navy strip that isn't there.

People asked for it back

SSMS has its own feedback site, and Blue comes up there. What happens to those requests is the part worth watching.

November 2025, filed against SSMS 22:

December 2025, from someone who had just upgraded and wanted their workspace back:

And June 2026, which is the one I keep thinking about, because Microsoft removed Blue for accessibility reasons and this is an SSMS 22 user describing the replacements as an accessibility problem:

Both things can be true. Blue really did have contrast problems for some people, and the palette that replaced it really is failing others. That's what makes just pick a different theme an unsatisfying answer.

The thread that actually made me build this came from a DBA who asked for the classic theme as an option, hand-installed a blue theme into SSMS 21's extensions folder when the answer was no, and then upgraded to 22:

Where SSMS theme requests go

Now look at how they were resolved. The first was closed as Other Product. The last was closed as Out Of Scope. The accessibility one is still sitting on Need More Info. A fifth, filed in January 2026 and titled "Restore old (blue) theme as default", was closed as a duplicate of a Visual Studio ticket. Not one was closed by somebody deciding SSMS shouldn't have Blue. They were closed because the SSMS team doesn't own the answer.

That's a fair answer, and the SSMS FAQ backs it up: SSMS is Visual Studio underneath, so its theme list is Visual Studio's theme list. It also explains why the SSMS side of this looks so quiet. The demand didn't evaporate, it got forwarded.

You can see where it landed. "Once more, we ask for the Blue Theme back in VS 2026" and "Bring Blue theme back for Visual Studio 2026" carry 215 and 174 votes and 286 comments between them, and in May 2026 Visual Studio Magazine reported that two of the top three issues on Microsoft's entire Developer Community site were requests to bring the blue theme back. Every DBA who filed against SSMS and got redirected is somewhere in those numbers.

Then in June 2026 the Visual Studio team did ship something. Version 18.7 added a Theme colors page that lets you override individual color tokens yourself, and the biggest Blue request was marked Completed on the strength of it. Microsoft's own migration guide also answers "Where is the classic Blue theme?" by suggesting you "install the community Blue Steel theme if you want a closer homage."

Microsoft then asked the thread whether that solved it. Seven people picked "Yes, it works." Nineteen picked "No, I tried everything — please re-open this." A box of color tokens is a set of controls. What people keep asking for is the theme, in the dropdown, working.

Why it isn't just a color swap

The obvious question, and the one I asked before starting: the old theme file still exists, so why can't anyone just load it and be done?

A Microsoft engineer answered that in the Visual Studio thread, and it's the most useful thing anybody has written on the subject:

The numbers are in Microsoft's own migration guide: roughly 1,806 color tokens across 34 categories in the older system, down to 229 tokens in four categories for a Visual Studio 2026 shell theme. As design work that's an improvement, and I'd have made the same call. As a compatibility story it means a color that used to belong to exactly one thing now belongs to several, and the old theme file is written in a vocabulary the window no longer speaks.

I loaded it anyway, because you have to start somewhere. It got maybe forty percent of the way there and then fell apart in four specific ways, which are worth describing because they turned out to be the entire job.

One color, two jobs

Old SSMS gave the document tab channel its own color slot. The new shell hands that same slot to the toolbar tray as well. Set it to navy and you get the navy tab strip you wanted, plus navy toolbars the moment the window loses focus. There's no third value to reach for. The slot does two jobs and you only get one answer.

Text that doesn't know what's behind it

This is the one that surprised me. Older versions of SSMS had a lot of little places that worked out a text color from the background they happened to be sitting on. Dark background, light text. Light background, dark text. SSMS did that arithmetic for you and never mentioned it.

The current shell leans on a single global text color instead. That's fine when your whole window is one family of tones. It falls over the instant you make one strip navy and leave the rest light, because the tab labels, the little gear and ellipsis glyphs, and the collapsed panel names all keep the same dark text they had before. You end up with charcoal-on-navy, which is technically a color scheme.

Backgrounds that aren't there

Unselected document tabs are transparent. They have no background of their own; whatever is behind them shows through. That's a sensible way to build a tab strip, and it means every tab inherits the decision you made about the strip. Change the strip and you've changed every unselected tab's background without touching a single tab.

Those last two compound. Painting the strip navy is the very thing that makes the labels unreadable, and there's no separate label background to go fix it on.

Settings that do nothing

My favorite discovery: the theme file has a color slot for inactive tab text, and it had been set to white the entire time. Inactive tab labels still rendered dark. The new shell simply doesn't read that slot anymore. Nothing warns you. The value sits there looking correct and has no effect on anything.

Now multiply that by every slot in the old vocabulary that didn't survive the move. That's what "not practical" means in the engineer's reply above, and it's why the token editor Microsoft shipped in June doesn't quite finish the job either. Restoring Blue properly means working out which slots still connect to which pixels, then writing real code for the ones that no longer connect to anything. That's a project rather than an edit.

How SQL Shades does it

SQL Shades has always been in the business of reaching into SSMS where it isn't strictly invited and coloring things the theme system can't. Classic Blue is that idea applied to the window chrome.

The theme file carries everything it can still carry honestly. Where a color slot still drives the surface it's named after, that's where the color lives. The inactive tool window headers turned out to be one of these, which was a nice surprise partway through: they'd been hand-painted at runtime for a while before I noticed the theme could just do it, and moving the color back into the file deleted a repaint, a visible flash, and a chunk of code.

Everything the theme file can no longer reach gets painted at runtime, per element, while SSMS is running. The navy strip, the white tab labels, the glyphs, the collapsed panel names. That layer runs only when Classic Blue is your selected theme and only on SSMS 22.

Two decisions matter more than the rest:

The gold selected tab is left completely alone. SSMS already knows how to paint the tab you're looking at, and it does it correctly. Overriding it would have meant fighting the same code every time you clicked a different tab, and losing occasionally, in front of you.

And the theme file's own values stay readable by themselves. If a future SSMS update rearranges the window and the runtime layer can't find something, that surface keeps its light color and stays legible. Worst case you get a theme that's less navy than I intended, which is a much better Tuesday than white text on white.

The part that took the longest

Focus. In real Blue, clicking Object Explorer dims the document tab you were working in. It's a small thing you never consciously notice until it stops happening, and then the editor looks permanently active whether you're in it or not. The first version of Classic Blue only understood selected and not selected, so that signal was missing entirely.

Getting it back meant modeling a third state and asking SSMS the right question, which turned out to be the same question the tool window headers were already answering for themselves. Clicking a panel deactivates the document view by the simple fact of activating the panel. Once the tabs listened to that too, they went slate with white text like they used to.

What it doesn't do

In the interest of not overselling my own work:

• Classic Blue is a recreation rather than the original file. It's built to match SSMS 20's Blue closely, and where SSMS 22 and SSMS 20 genuinely disagree about what a surface even is, I picked the reading that looks right over the one that's technically faithful.
• It ships to SSMS 22 only. SSMS 18 through 21 already have the real Blue, and handing those versions a near-identical copy would have been silly. SQL Shades treats the two as the same choice, so switching on 22 won't drag your other installs off native Blue.
• It's a theme, not a rendering engine. Anything in SSMS that paints itself with hardcoded colors and refuses to listen to anybody still does that.
• Credit where it's owed: the theme file started life as a fork of Mads Kristensen's Blue Color Theme for Visual Studio, under Apache 2.0. Almost every value has been replaced since, but that's where it began and the notice ships in the product.

Getting Classic Blue

• Install SQL Shades.
• Open Tools → SQL Shades Settings.
• Choose Classic Blue.
• Click OK, then restart SSMS.

It's in the free edition. No key, no trial timer, no email address.

FAQ

Does SSMS 22 have a Blue theme?

Not out of the box. SSMS 18 through 21 do. If you want Blue on 22 today, Classic Blue in SQL Shades is the way to get it.

Is Classic Blue really free?

Yes. It's in the free edition alongside Basic Dark, the GitHub themes, and the colorblind-safe themes. Pro adds more themes, scenes, and customization on top; Blue isn't behind that door.

Will it change how my other SSMS versions look?

No, and this took deliberate work. SSMS shares one settings file across every installed version, so picking Classic Blue on 22 would happily have reached back and switched SSMS 18 off the real Blue onto my copy of it. SQL Shades treats the two as the same choice instead, so your older installs keep the genuine article.

What if Microsoft brings Blue back?

Then I'll be delighted, and you can switch to it in one dropdown. Nothing about SQL Shades makes that harder.

Does it slow SSMS down?

No noticeable impact. It's a theming layer, and you can switch themes or uninstall whenever you like.