July 30, 2025 at 1:04 am
Hi everyone
SS2022 has been around for a few years now so I have been considering upgrading with the assumption that it is "stable" and known issues have been addressed but I could be wrong in my assumption. I am currently using SS2019. Is it worth upgrading from SS2019? Have there been any issues with SS2022 that I should be aware of? I also use SSIS so I don't want to break SSIS either.
Any feedback / guidance you can offer is really appreciated.
Thank you
July 30, 2025 at 2:35 pm
My opinion, upgrading is pretty safe. If you are concerned, set the compatibility level to 170 150 to keep your databases working like 2019 and without any 2022 features.
I'm slowly upgrading to 2022 myself. I have a lot of instances to do, but my production ones are getting there. If you are concerned about SSIS, SSIS services will keep both versions so nothing should break. I'd recommend upgrading the packages to 2022 as time permits (preferably as you are upgrading, but depending on the volume that may not be reasonable).
I'd also recommend doing it on test systems first and seeing the impact. Also, run the data migration assistant to see if there are any breaking changes or behavior changes you need to address before upgrading.
Now, if you want to know about issues with SS2022, I'd check the Microsoft docs for known issues; latest CU (CU20 at the time of writing) has 1 known bug - https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2022/cumulativeupdate20
The fun thing is that your specific environment MAY get hit with a known or unknown bug when you upgrade based on the various configuration options you have set. Upgrading from 2019 to 2022 is a lot lower risk than a bigger jump, but I still always run the assistant AND upgrade test first.
If you do a migration upgrade (instead of in-place, which is the recommended way to go), you can run things side by side in the test environment to assess performance impact and query results so you don't get hit with any surprises. If you do an in-place upgrade, I'd run some baseline scripts first to get a rough idea of performance then upgrade the test system and re-run the baseline scripts to check for performance degradation. Make sure to capture execution plans too - it COULD be performance degradation is due to outdated statistics or indexes needing to be rebuilt due to the upgrade.
EDIT - not sure what I was thinking, but 170 isn't 2019... 150 is 2019.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
July 31, 2025 at 12:29 pm
I've always advocated against inplace upgrades ( as it may leaves potholes or ports , ... open / active )
I suggest actually migrating to a new OS with the SQL Server version of your choice.
Is there an urgency to get to SQL2022 ? Why not wait until SQL2025 is RTM ? ( and hope they fixed a ton of regression issues, etc )
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
July 31, 2025 at 2:59 pm
I do agree that in place is not the best way to go, but sometimes it is the best of a bad situation. The way my environment is set up, in place is the best option for upgrades to minimize downtime and impacted people. I can't take the whole company down at once, but I can impact a few departments at a time to do my upgrades. We have a lot of instances running across a handful of servers with failover in place. Upgrading to a new OS, based on how we have things currently set up, means we need to move a bunch of instances all at once to the new server plus update a bunch of SQL aliases which could mean end users are unable to work if the aliases don't get pushed out to all machines during the outage window. Plus, due to licensing of our failover software and current hardware configuration, we need to move ALL of our SQL instances (30+) over at once and that is just not reasonable with a migration based upgrade.
My opinion though - going with 2025 RTM means you MAY get hit with NEW bugs from the new version. I like to wait for at least SP1/CU1 to come out so some of the bugs are fixed before I jump on an OS or new MS tool. And if you are upgrading more than just SQL Server (SSIS too), there is a bit more risk the more versions you jump AND offhand I am not sure if SSIS 2025 works with VS properly yet and I'd hate to be in a situation where I can't support something.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply