August 19, 2026 at 1:41 pm
Putting this here as we're currently on SQL Server 2019 installed on Windows Server 2019, all hosted as VMs in Azure. We've recently been handed down a directive to upgrade to Windows Server 2025 by the end of Sept (which, needless to say, is NOT going to happen by that time.)
My preference would be to stand up new VMs to replace the existing VMs, clean installation of SQL Server 2025, and migrate the databases to the new servers from backups. However, there's also some wrangling going on higher up in the organization that may nix the cost of having duplicate VMs, even if only for a couple weeks / a month, which would then put me on a collision course with an in-place OS upgrade. Lets leave out migrating the databases to Azure SQL / Managed Instance, as some of the databases use features not available in either of those (Filestream, linked servers to Oracle using Oracle Wallets,) so while that's the end goal (currently,) that's also not in the cards for this particular situation.
So what's everyones' thoughts on doing an in-place upgrade of an OS when it comes to SQL? Have you done it? Did it go smooth, or where there problems, or did it completely blow up? Am I worried over something small? Being VMs, we could snapshot the VM prior to doing an upgrade, I'm thinking ideally with the SQL services stopped (the snapshot also ONLY snaps the OS volume, SQL is installed to another drive on the VM with the databases on their own drive,) to minimize the number of parts in motion during the snap and upgrade, IF we / I go down the in-place route.
August 19, 2026 at 2:08 pm
Definitely use new VMs. Too many installation settings could matter here. The new VM approach also allows you to test with a db to two without having to wait for all dbs to be converted (assuming your instance holds multiple user dbs).
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
August 19, 2026 at 2:55 pm
It's a risk. I've had it go smoothly, and not smoothly. The risk is downtime while you sort out OS issues. If the company doesn't want to pay for separate VMs to reduce risk, than I'd get someone to note that in email so if you have downtime, there's a trail you warned them.
I assume you are just OS upgrading and no SQL patching? In that case, you should be able to cheaply set a new VM up and then snapshot disks for the new vm and attach the dbs to see if things work. I've script out what you want to test so you can quickly get that done and then remove the disks and shut down the vm to reduce costs.
Done with some prep, this ought to be minimal costs. I'd definitely want to shut down these vms when not actively testing
August 19, 2026 at 3:06 pm
IF I can get the time / funds, I'll definitely go with the new VMs (and migrate to a newer SQL as well,) but my concern is higher management is going to nix the new VMs (they're on a CRAZY cut-costs binge right now.) And we're also going to be having to do this to our web servers, which the admin on those might be asking for the same thing as myself.
Although, the web admin is a bit more open to an in-place for his servers for a couple reasons, which is helpful.
If my supervisor were here today, I'd be chatting with him and letting him take it to the higher-ups. As for getting whatever they decide in writing, oh HECK yes. Especially if it's the in-place upgrade of the OS!
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply