- Hosts: Steve Stedman / Mitchell Glasscock
- Topic: SQL Server Upgrades
- Recording Date: February 10, 2026
- Listen on Spotify!
Stedman SQL Podcast Season 3 Episode 4 SQL Server Upgrades
Steve Stedman and Mitchell Glasscock discuss SQL Server upgrades, comparing in-place upgrades versus new server migrations. They highlight the importance of upgrading due to end-of-life security risks, such as SQL Server 2016’s July cutoff. In-place upgrades are quicker but riskier, with potential downtime and limited rollback options. New server migrations offer lower risk, more testing, and better rollback mechanisms but are costlier and time-consuming. They recommend the latter for mission-critical systems and those moving to the cloud. Best practices include thorough testing, backup plans, and considering hardware refreshes. They also promote their tool, Database Health Monitor, for migration assistance.
Podcast Transcript
Steve Stedman 00:16
Hey everyone, and welcome to the Stedman SQL Server podcast. This is season three, episode four, and I’m Steve Stedman, and today Mitchell Glasscock joins me. Mitchell and I are with Stedman Solutions. Welcome Mitchell.
Steve Stedman 00:33
Well, I guess I should say thank you for being on the show. It’s always great to have a guest. Today we’re diving into one of the most common and sometimes more stressful tasks that DBAs face, upgrading your SQL Server instance. So should you do an in place upgrade on your existing server or spin up a new one and migrate everything over? What we’re going to do is we are going to compare the two approaches head to head, so you can decide on what’s best for your environment. If you get to the point that you need help with your SQL Server upgrades, or need to jump from 2016 to 2025 or something like that, we’re here to help. We do SQL Server upgrades all the time, and hopefully we can share some wisdom in this podcast. But if you’re still stuck, we’re happy to help. So on to the first segment. Why do upgrades matter? The big picture? Mitch, I know we’re working on several upgrades for clients right now. Why? Why do we need to upgrade? What? Why do the clients want to upgrade?
Mitchell Glasscock 01:37
I think one of the biggest reasons that we see upgrades is clients. Like I said, it doesn’t even have to be clients. It’s just production servers in general. They are. They stay on one version, because that’s what works. But eventually that version reaches an end of life. It does not receive any new security patches. There’s the end of life, and then there’s the extended end of life. So that extent, once that extended end of life hits, there is absolutely no more security patches rolled out for that SQL Server, and that is when it becomes pretty imperative to roll to a new SQL Server version.
Steve Stedman 02:16
So example, there’s still a lot of people out there running SQL Server 2016 and although there’s a lot of enhancements since then in 2017 2019 2022, and 2025 SQL Server 2016 is a pretty solid product. It really is. And however, it’s coming to end of life where there is not going to be those patches like you talked about there it’s going to be higher security risk. And so people at this point, I think the, I think the actual end of life date on that, if I remember correctly, is somewhere in July. But people are looking at, well, how do I get off of 2016 now? So I can get to something that’s actually going to be supported going forward. So when people come to that, I mean, the big picture is, you want to get to a place where you actually have security patches. So many times, I’ve heard stories about ransomware, and if you haven’t taken my free ransomware class, please check it out. But I’ve heard about ransomware getting in because people are running old versions of software, whether it’s their database or their web server or whatever it may be, and ransomware gets in through some hole that’s been known about for 15 years. There’s a lot of other reasons too. For instance, like software vendors, you might be running some off the shelf product where they tell you, we only support this version, and suddenly 2016 was the only version that they ever supported, and now they’re telling you have to be on 2022 or 2025 so there’s a lot of reasons, good reasons to do this. A lot of the common things are also like hardware refresh. I mean, oftentimes people will be running in an environment where the hardware that their SQL Server is running on is completely outdated. And, I mean, we went through this with a client, gosh, when was it? It was a three step move, where they were running on such old hardware that jumping to just the modern equivalent of what they had purchased was just so much faster. I mean, it was like night and day performance. So hardware refreshes are important. Also moving to the moving to the cloud or to Azure. I mean, that’s a another reason people upgrade. If you’re unfortunately, you’re stuck on like, SQL Server 2012 on prem right now, and you’re trying to move to Azure. I don’t know if Microsoft Azure is even going to give you an option for SQL Server 2012 Hopefully they don’t. So then the other thing is, a lot of times people look at it as performance improvements too. Like I mentioned, you’re gonna go to newer hardware, faster hardware. Get newer options, like 2019, and 2022, and 2025, have RCSI level. I mean, it’s been there on older versions of SQL Server, but it’s really matured on those versions to the point that it’s you can get a pretty big performance boost. Just by going to SQL Server 2022 for instance, and turning on RCSI. Any other common triggers you can think of there Mitch that?
Mitchell Glasscock 05:08
Well, I think in the past couple of years, one of the biggest ones we’ve seen is that move to Azure, or any cloud based solution, a lot of people are moving away from the hard racks, and they’re moving to Azure and doing more of a group managed service there, where they can get more options than just doing an in house hard rack, but that that kind of breaks away from the main conversation of, is it going to be an in place upgrade, or is it going to be a spin up a new server and jump everything over to that new one. So it’s, it’s kind of 50/50, on what we’re seeing there.
Steve Stedman 05:44
So a couple of quick stories on this, the upgrades that I’ve been part of, or I’ve seen, where things have been good and where, well, usually they’re good, because we do this a lot, we know how to make it good, even if something goes bad. But we did a migration. Gosh, this one must have been eight or nine years ago. And I know eight or nine years ago doesn’t sound that long to some people, but the internet, the speed of VPNs and all that, has changed a lot in that time as well. But eight or nine years ago, we did an upgrade. It was close to a one, one terabyte database. And not only were we upgrading it from the version of SQL Server, we were also moving it to a different site, to a different colocation facility. So we had to move, make the move across a VPN connection at that point. And so that was an upgrade. We had to do it not as an in place upgrade, but as a new build out, and we moved everything over there. And the thing we ran into was that to move that amount of data over the VPN that was in place at that point in time, or even today’s VPN, to move a terabyte, takes a while. It would have taken, like, I don’t know, at that point in time, it was something like 18 hours of downtime in order to be able to take the databases offline, move them over and then bring the server back on.
But what we were able to do was to do a migration using a modified version like log shipping, in order to be able to do a full restore, and then to replay the logs to get it up to date. And in the end, we ended up doing the final switch over with about five to six minutes of downtime, and in order to be able to move that whole database, now we kind of cheated, because we moved the whole database ahead of time, and then just got it caught up with differentials and logs, but the outcome was the same because we got it moved, we got it switched over with very little downtime, and it was a big success. Other times I’ve seen it go wrong is when you’re doing an in place upgrade and people don’t have a good rollback mechanism. And when that happens, if something goes wrong, you’re in a position where you’ve got a dead server until you figure out how to make it work. And I’ve been on one or two of those that where somebody started the upgrade, and then once it went wrong, they called me to get involved and figured out how to fix it, and then eight or 10 hours later, we had it fixed by uninstalling and reinstalling the original version of SQL Server and restoring everything. That’s not the way to go.
So before we jump into the rest of this, let’s hear a quick word from our sponsor. Is your SQL Server slowing down your business, slow queries, bottlenecks and unexpected issues, eating up your time, introducing database health monitor, the powerful tool built by our team at Stedman solutions, get real time insights into performance with over 100 built in reports, index analysis, wait stats tracking and proactive alerts, quickly diagnose and find problems before they impact your operations with an easy to use interface for DBAs and developers, monitor unlimited servers, tune queries and keep your databases running healthy and fast. Download a free trial today at Databasehealth.com and take control of your SQL Server performance.
Okay, so what exactly is an in place upgrade? Well, the key thing with an in place upgrade, I guess I should also point out, before we go too far, if you’re one of those people that comes along and only listens to part and then drops off, make sure if you listen to our us talking about in place upgrades, you don’t run off thinking this is necessarily a good thing to do. Stick around and make sure you listen to the alternative in the next section, but an in place upgrade. I generally don’t recommend this, but what you’re doing is you’re basically taking an existing version of SQL Server that’s or a server that’s running SQL Server, you’re popping in the updated install media for the newer version, and you’re running it, and boom, your SQL Server is upgraded. And now running on a newer version of SQL Server. If you get lucky. I say it that way, if you get lucky, because there’s a lot of cases in doing this where if anything goes wrong, something could fail along the way, and you’re stuck without that SQL Server. So let’s talk about some of the pros and cons around this Mitch.
Mitchell Glasscock 10:23
So some of the pros, I mean, it’s, it’s just simpler because you’re not building out that new server. I mean, I’m kind of jumping over into what the build and migration version is, but you’re not building out a new server. So it’s a bit easier to just handle one machine, and it’s a bit faster because you’re not having to migrate everything over at the same time, you’re also looking at the lower hardware cost. Building out the new server is going to cost more money, especially if you’re doing it like on Azure. You’re running two machines concurrently, you’re just going to increase costs there, inevitably, and then shorter overall project timeline. In the small setups, it’s just quicker to execute less things, to test less things to set up. But it doesn’t always mean that that’s the better option.
Steve Stedman 11:09
So an example, example on that shorter timeline. I mean, there’s servers that I’ve worked on that have been my own test servers that I know. Worst case scenario, if something goes bad, I’m just going to rebuild the whole server from scratch. I’m not that worried about it where if I want to go, I’ve gone from different versions of SQL Server to two to five years newer versions. I’ve just popped in this install media, ran it and upgraded it, and all was good. 20 to 30 minutes later, the whole project is complete. However, that’s risky, and let’s jump into some of the cons and risks. So one of the reasons I see is that it’s a higher risk is that you’re really destroying, not destroying. Let me rephrase that. You’re modifying a production server that if something goes wrong, you don’t necessarily have a good way to roll it back. Now, if you’re going through and doing that upgrade, and something happens halfway through and one of your data files is destroyed, that’s not very common, but it could happen. How are you going to get it back? Now, one of the ways to mitigate that risk is if you’re running on a virtual machine, to do a complete virtual machine snapshot. And pretty much anytime I’m going to do an in place upgrade, I want to make certain that I’ve got a virtual machine snapshot that I can roll back to other risks. Well, any you can think of there.
Mitchell Glasscock 12:33
Well, I think going off what you said, it’s you need to have those rollback methods, but you can’t always test those rollback methods before you commit to doing the upgrade, especially if you’re doing like a production server. You can’t say, Okay, we took a snapshot today. We’re going to do the upgrade, and then if it all goes wrong, we’re going to roll back. You can’t just try the rollback prior to the upgrade or it’s not always an option to even try that.
Steve Stedman 13:08
Yeah, there was one I did it in place like that, where the administrator of the virtual machine, the VM administrator, basically said, Yeah, we got a good snapshot. Anything goes wrong, we can roll it back. And something went wrong. I figured, okay, no problem. We need to roll it back. And he rolled it back, and it turned out that after rolling back that he’d taken the snapshot like 12 hours before the upgrade, and 12 hours of data would have been lost. 12 hours of production data, including financial transactions, would have been lost had we used that. So then what we had to do after we rolled it back, we had to switch back to the original failed upgrade version and then go through and actually fix it. And that took number of hours to get it before it was actually running again. So rollback is absolutely painful in those situations, or it can be. I mean, if you’ve got, if you practice it, you know you’ve got a good VM roll back. Well, there you go. Another disadvantage that I can think of, or a con with it, is you’re stuck on the current hardware or operating system, unless you do a separate upgrade there, and I don’t like to do an OS upgrade and a SQL Server Upgrade on the same day in the same downtime window. You might be a little bit more wild and crazy than I am, if you want to try that. But the problem is, if you do an OS upgrade and you do a SQL Server Upgrade on the same system in the same day, you might find out that there is something horribly wrong after the process, and you may not be able to pin down whether it was caused by the OS upgrade or caused by the SQL Server Upgrade. So I usually like to if we’re going to do an OS upgrade, to do that at a different time, for in place, at least, so that we do the OS upgrade like. Two or three weeks at a time, and then do the SQL upgrade so that you know if something did go wrong, which half of it is causing that problem. So okay, so when would you want to choose an in place upgrade versus looking at other options?
Mitchell Glasscock 15:17
Truthful option, never. But in a in a perfect world. I mean, a perfect world is never but in a real world situation, I would go with, if you’re running a small environment, especially a small testing environment, that’s the perfect, perfect opportunity to do it. I would say, never do it with a production server. But in the inevitable you need to have that checklist. You need to have rollbacks. You need to know that your rollbacks are good. You need to have backups. You need to have all these things set out in place before you just jump in. Say, Hey, I have my install media. Let’s do it.
Steve Stedman 15:56
And I guess one other thing we should point out too is that if we’re just talking about a service pack or cumulative update. I’m usually fine doing those on a server and in place upgrade on those, because that’s, I mean, those are minor version bumps. We test them in lots of environments. We do probably hundreds of those, and very rarely do those have a problem. That’s a whole different scenario. But what we’re talking about here is when we’re going from a full major version of SQL Server, 2019 to 2022, or 2025, or one of those. So I guess the other one too is if, if you’re, if you’re on a tight budget, in a tight timeline, where you just can’t afford the time to build out a new server and take the time to do it right, and you’re willing to take that risk, you might get away with it. Now, the problem is, when you try and go that way, you may end up some of the time taking FAR more time and far larger budget to get your system running again, too.
Mitchell Glasscock 16:56
I think from update or upgrade, whichever one you’re doing, the most important thing is backup, backup, backup. Always have backups and double check backups.
Steve Stedman 17:06
Another thing to think about, whether you’re doing a in place or a migration build, is always run the Upgrade Advisor or the database migration assistant. I think the names changed recently in order to be able to go and analyze and make sure that whatever’s in your database as you’re doing it, that you’re not you don’t have any deprecated features that are going away in the next version, or if you’re working in dev or staging, to make sure you test it there first before doing it on production. Okay, so that’s kind of the in place upgrade option, and usually we really don’t recommend this, and I would rather spend the time to do it right than to do an in place upgrade. And, you know, some people hear that and they say, Oh, well, rather spend the time. Well, that’s just billable hours. You just want to make more money at it. Well, what? Even when we’re working with our managed service customers who are on a fixed monthly price that it doesn’t matter whether we do it fast or whether it takes three weeks to get it done. It we still make the same amount of money. In that case, we still always try and stay away from the in place upgrade, because even though it is the absolute fastest way, usually, to do things. It’s not the most reliable, and it can lead to a lot of headaches. Okay, so anything more on in place before we move on?
Steve Stedman 18:33
Okay, so what is a new build and migration option? The alternative for doing the in place upgrade. What does that involve?
Mitchell Glasscock 18:43
Well, we’ve kind of teased it a little bit. I mean, it’s just building out a new machine, setting up that new server, and then bringing over all your databases to that new server from the old one. But it gives you a way bigger testing gap, where you can have that server up for months. I mean, you could have that server up for a year and just run tests on it until you’re comfortable to bring it to that production stage.
Steve Stedman 19:10
Yep, and we’ve had some clients that we’ve worked with on this where we built out that built out that new server, they tested against it. Well, we migrated to database databases, of course, they tested against it, and within a within two or three days to a week, they were thumbs up, ready to go. And then we did, we scheduled and did the live migration and re move the databases over again for that final move. There’s others that we’ve worked with where, yeah, they find out some of their systems don’t work quite right. And a couple, I mean, they’ve even taken over a year from when we’ve done that to when they were ready to start using that other server. We didn’t have a lot of control over that, because that was their internal systems that were kind of putting the block on that. But we were at least able to find out about those issues before going live, and they took that year to get things fixed rather than having everything broken. At the time we went live with which was what would have happened with an in place upgrade.
Mitchell Glasscock 20:04
Yeah, that’s kind of the beauty of it, too, is, I mean, if you do bring over those databases and you, you’re starting your testing on it, you find, hey, this off the shelf product that I’ve been using doesn’t work right, or it doesn’t work as I expected on this new version. You can communicate with vendors. You can do in house testing, if it’s an in house product, and you can get that fixed before you even run out to that new version. So that’s where you can’t do that in the in place. That’s what we’ve kind of been talking about this whole time.
Steve Stedman 20:35
So a couple of other things that you need to be concerned with when if you’re doing a new build and a migration is that you’re not just bringing over the databases to the new server. You need to also bring over the logins, and usually we’ll, when we do that, we’ll look at the list of logins work with the clients and determine which ones we want to move and keep with the exact same passwords and access permissions, and determine which ones are obsolete or not needed anymore. In addition to logins, we want to bring over jobs and link servers and any other like database, mail, configuration, those kind of things, so that the new server will be configured to have whatever features were available on the old one that are needed going forward. That is an extra step there. That is not, yeah, that’s not the case if you’re just doing an in place upgrade. All right. So one of the things that with the new server build migration is that it is way lower risk. And we always say it this way, that when we do the migration to a new server, once the databases are moved there, we’re just going to shut down the old server. Well, if anything goes wrong in that upgrade process and we want to fall back, all we have to do is just turn on that old server and we’re running the same as we were running before we started this upgrade. That’s a really great rollback mechanism, and we’ve had to do it a few times where we ran into things where we found out the new server was not something wasn’t quite right with the networking or the routing or something like that, that people weren’t able to connect. So, yeah, another pro is testing. I mean, like we talked about test, test, test, and that’s really the only way to know for sure that your system is going to work on that news on that new SQL Server is to test against it. Also. I mean, when we’re doing a new build out like this, the opportunity for hardware or OS or refresh going to the cloud. I mean, it’s a lot easier this way you can then decommission that old system, whatever it is, and move to a new server.
Mitchell Glasscock 22:33
Yeah with more and more individuals that are on the cloud, it’s easier to just go with this build a migration, because you can just build a parallel server and start out the build there. You don’t have to do that in place migration on or the in place upgrade on the cloud and now the new build.
Steve Stedman 22:53
Doing it this way is really my number one recommendation if you’re doing major version from anything other than like a service pack or cumulative update. Okay, so some of the cons, then, why would why would you stay away from this?
Mitchell Glasscock 23:08
Inherently, it’s just cost. It’s it. There’s no way to get around it. It’s going to cost more money, because if you’re spinning up a new server on the cloud, you are going to be incurring double the cost from what your first one was, and then the time consuming part of you have to set up that new server, and then you have to set up the new databases, bring over the jobs, set up the configuration, the Logins it. There’s no way to get around the time constraint that you are adding to it, but that time constraint the more upfront cost saves with the lower risk at the end.
Steve Stedman 23:47
So it’s a balance. And just to point out there, again, if you’re with our managed services, we don’t cost any more either way we go there. It’s the just the time and the amount of testing, and then the cost of the server, the virtual or the virtual machine while you’re doing that as well. So okay, so when to choose the new server build out and migration. Really the key there is, if you’re working with a mission critical system, you have high availability needs. If you’re working with infrastructure upgrades or larger complex setups. I mean, the key here is, is your data important to you? And if it is, this is the way to go. Yeah. I mean, one of the things to recruit reduce downtime with this is doing things like log shipping, maybe not standard log shipping, but where we just do a full we do manual log shipping to get everything over there at the last minute to reduce downtime, like we talked about earlier, making sure we script out all the logins and jobs. And that’s one of those things that with Database Health Monitor, we’ve got some options in there to be able to help script out those logins so they can be migrated from one server to another. All right, so before we go into the comparison, I guess, have you ever thought about being a guest on our show?
Are you interested in being a guest on the Stedman SQL podcast? If you are just reach out to us and we can talk about what topics, things you want to cover, or talk about anything relating to SQL server, database health monitor or about our company, you can reach out to us at https://Stedmansolutions.com/guests, or go to the podcast page and click on the guest link, fill out the form and find out if you’re going to be a guest on one of our future episodes. Okay, so Mitch, let’s go into a head to head comparison here, on in place versus new server build out in migration. downtime,
Mitchell Glasscock 25:45
I mean, in place is going to be shorter inherently, just because of the time that you’re using to build up the new one. But like we said, the trade off is that you might be risking more time at the end of it. So in place, in a perfect world in place is always shorter, but you’re looking at that non perfect world situation there.
Steve Stedman 26:08
Yeah, okay. So as far as the risks that we look at, I think the in place upgrade is way higher, and the new build out is significantly lower new build. There’s way more rollback options, way more methods to test and confirm that things are good before you ever even get to that final switch over date.
Mitchell Glasscock 26:35
Yeah, cost, cost, that’s a big one. I think, what do you think on that we kind of, we covered it already with the talking about the big picture for the migration. But I think again, it’s weighing the risk to the cost. If you can afford it, you should go with it.
Steve Stedman 26:48
So the in place is definitely cheaper, usually, as long as nothing goes wrong, the build out and migrate is higher priced, typically just because of the time and multiple servers involved. But yeah, yeah, it can save money long term. So testing and rollback, I think on that one, migration is the big winner, because you’ve got way more options for testing and way more options for rollback. And I think as far as flexibility, well, if you’re doing the in place upgrade, you’ve got less options for upgrading the hardware or operating system at the same time. Yeah, I think this is one of those real some real world examples here. So working with a client, we have one client we work with who has one server that just log ships over to a second server, and then that second server is used for some reporting purposes. So that was just a small reporting server. They understood that if, if that server went down, it wasn’t a big impact on their business. On a server like that, we did the full version upgrade from 2017 to 2022, saved weeks of work on that one. It worked great. But we also knew that they had great virtual machine snapshots that we could roll back to if they needed it, that that was a system that, I mean, they also understood that if it was down, or if it was gone for a few days while it was being repaired, it wouldn’t be the end of the world for them. We had a high traffic OTP system. What we did was we set up, I think I mentioned this earlier, effectively log shipping, where we had one of them running, we had the log shipping over, and our cut over was just minutes instead of hours. Now there was a whole lot of prep time and practice on that, but the actual downtime or switch over was almost nothing, just five to six minutes. So what are you going to do to make the decision? What can you ask yourself?
Mitchell Glasscock 28:46
I think the biggest question is, what’s your risk tolerance? I can tell you what I would do 99% of the time. I would do a new build out, and then the new server. But if you have the risk tolerance, like you said for that, the one where it’s a log shipping reporting server, where the data doesn’t actually matter that much. You’re just pulling reports. Yeah, I could, I could accept the risk tolerance there. It’s easy. It’s easier to talk to a client about that. But if you’re saying this is my financial server, and I do paydays every week off of this, no way am I going to tell you? In no world would I ever say, Yep, this is a great server to do an in place upgrade with.
Steve Stedman 29:27
So, yeah, other things just simply, can I afford the downtime? How critical is the system? Am I going to be refreshing Hardware and Building a new server anyway? And also, here’s a here’s a key one two. What’s your team’s experience level? If something does go wrong, who’s there to help you? How are you going to get back now, if we’re doing it, we’ve got the experience level, and we’ve recovered from a lot of weird things that have gone wrong over the years, and we know how to do that. Not everyone has that in house. Really what it comes down to what you should ask yourself. This comes from when my boys were in Boy Scouts, the scout master used to have a saying that was, ask yourself, What’s the worst thing that could happen? And if that’s if that happens, can you live with it? And if it’s an in place upgrade, the worst thing that can happen is your server’s down while you rebuild it from scratch. If you’re doing an in place upgrade, the worst thing that could happen is you just simply fail back to the previous server. Big difference there. Okay, so let’s move into some just some best practices, ideas and gotchas and for either approach, because people know, I mean, people have to do upgrades eventually. Either way you go, you’re going to have some risk, some things you need to consider, any thoughts, what to consider there Mitch.
Mitchell Glasscock 30:44
I mean, like we said earlier, for both, it’s backups, backups, backups. What’s your method for saving the machine? What’s your method for saving the SQL Server? What’s your method, I guess, what? What is your fallback plan? It you need to have that universal fallback plan before you start anything.
Steve Stedman 31:04
Another thing to keep in mind is compatibility level checks and what deprecated features are there? What about orphaned users? What about certificates or encryption application testing those kind of things, whatever you’re going to be doing, you need to make sure you think about those. This is something you want to plan carefully. And look at how you’re going to deal with large databases. Look at how you’re going to sync configurations, things like that. If your server relies on database mail, have you switched over the database mail to the new server? Things like that. Another thing you can think about too is consider an Azure managed instance or an Azure SQL Server VM as a new build target for they call it future proofing. Sometimes, I don’t know if I necessarily think of it as future proofing, but as an option to those on prem servers, anything else under gotchas or best practices we can add there.
Mitchell Glasscock 32:03
No, I think we covered a lot of it. I mean, I’m always going to say Database Health Monitor is the best tool to start this planning process for either figuring out what you need for the new machine, or for figuring out any configuration on a new server, or just looking at the server health after the migration. So little, little self plug there.
Steve Stedman 32:27
Hey listeners, if you’re loving these deep dives and mind blowing insights on the Stedman SQL podcast, imagine getting even more exclusive episodes behind the scenes, bonus content and premium interviews you won’t hear anywhere else. Head over to our YouTube channel right now and hit that subscribe button turn on notifications so you never miss out on the content dropping every week. Join 1000s already unlocking the full experience, and don’t get left behind. Subscribe on YouTube today. All right, so one of the key takeaways on today’s episode is that the in place upgrade is quick and simple when risks are low, but a new build and migration gives you safety and flexibility when it counts, when you don’t want to lose data or have extended downtime. So which way have you gone in past upgrades? I’m asking for the listeners. Now if you’re listening to this, please drop a comment below on which way you’ve gone and maybe share some stories on was it good or was it bad, or would you do it that way again? I know Mitch was just a few minutes ago mentioning database health monitor is a great way to monitor and track this. So that’s where I want to say, try out database health monitor. There are some tools and options in there, like migrating users and things like that that will help you get your new server ready to go. So I’d like to say, Mitchell, thank you for joining me on today’s podcast. Thank you. And next time, please join us, we’ll tackle the Seven Deadly Sins of index and statistics maintenance, so thanks for listening to the Stedman SQL podcast. Have a great day.
Steve Stedman 34:20
I’m Steve, and I hope you’ve enjoyed this. Please click the thumbs up if you liked it. And if you want more information, more videos like this, click the subscribe button and hit the bell icon so that you can get notified of future videos that we create.