SQL 2019 instance with AG, across 2 Windows 2016 OS servers - OSin-place upgrade

  • Hi all

    Can I get some perspective from the community please on performing in-place OS upgrades on Windows servers, where there is a SQL instance layered on top. I have 2 Servers, Windows 2016 ones, that need upgrading to Windows 2022\Windows 2025 by end of year.

    There are 20 DB's on this instance, SQL 2019, and only one of those DB's is within an AG, the rest are Standalone. Just so happens the AG DB is an important one, wages for thousands of employees 😉

    The current setup is on-premise, both servers being Vmware servers. At some stage these DB's and their respective Application servers will end up in Azure, but that's a longer term migration, and for now, the company just want the existing OS updated by end of year.

    So I have 2 options:

    • Attempt in-place upgrade of both Windows 2016 servers to 2022 at same time, big bang, and hopefully no issues (Obviously have to stop sql services etc, and somehow check if there are any underpinning cluster features that could be impacted moving from 2016 to 2022, being as there is an AG in play)
    • Do it side by side. Get a new SQL instance spun up on 2 new servers, that have Windows 2022 OS installed.

    Now, either can be done, we have the resources for a new setup, but I need to consider both options and just outline risk.

    An in-placed upgrade sounds like it clearly would be quicker, yet comes with the downtime risk if things go wrong.

    Option B takes longer, but more controlled.

    Any opinions out there either based on experience of doing in-place, or of considering it previously.

    Ta much

    Tom

  • Myself, I'm paranoid, I'll always opt for a side-by-side if it's an option.  You've got a much better "bail out" plan if something doesn't work right (especially as you're not upgrading SQL at the same time,) it's just less stress.

    I'm presuming (I'm not familiar beyond the basics with AGs) that your current two servers are also a Windows Failover Cluster, if so, if it's possible, stand up one new Windows Server 2022, join it to the cluster and the AG, migrate the non-AG databases on server 1 to the new server, then let things "bake" for a week or so.  Decommission server 1 at the end of that, and stand up the second Windows 2022 and repeat the process.

    You'll still have to update connection strings for the non-AG databases, but you'll also keep the payroll database online near continuously which will make the employees and accounting staff happy.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply