One of the areas that is coming up more and more frequently with the ability to move from version to version of SQL Server pretty fluidly with the cloud is that of tuning and tweaking your systems as you upgrade.
Before any gets concerned, yes, these things apply if you’re working with on-premises systems, and these apply if you have hybrid solutions as well. The thing that has triggered this with our own work with SQL Server is that we’re going through some pretty active upgrade processes right now moving from prior version(s) of SQL Server to newer releases.
Join us each Friday at noon on Facebook and Youtube (brand new) for our weekly summary show with SSWUG.ORG’s Stephen Wynkoop – thoughts, ideas, a look at the week in review
It’s important to add a few steps to your testing before the actual cutover – steps that can help avoid surprises and can help make sure your systems continue as you need them to.
- Re-check error handling – make sure as you bring up the new systems that your checks and balances, error monitoring, error reporting and alert systems are functioning as you need, and that you’re updating your alerts for any new options that are helpful. Essentially, there may be cases where your cloud provider is monitoring your instance and you’ve set up specific alerts for conditions that are important to you. Make sure those alerts and conditions are deployed against the new database instances as well. It’s an easy thing to miss, until you’re left wondering why you’ve not been notified as expected about issues.
- Make sure you double check backup and restore operations, that you know of any process changes, permission requirements or other items that require intervention.
- Make sure you have aliased any server connections that you’re able to, and for those that you aren’t, keep meticulous records for systems that interact. As an example, we’ve had lambda processes that do work on an sporadic basis. Some of those talk to SQL Server. The connections from those processes have to be updated, and re-tested.
- Make sure any external encryption is updated as needed when talking to your new SQL Server instances. There may be key rotations or other updates needed to work with the new SQL Server.
- When all is said and done, don’t forget to STOP the SQL Server instance when you know, for certain, that all things are alive, well and functioning as you need. We had one set of servers that we were working with that had been kept online… just in case. Just in case something went wrong, just in case something had to be swapped back after an update. This can cause quite the surprise in billing changes, and not in a good way.
- On the billing front, make sure you know to transfer any reserved instances (AWS) or reserved capacity (Azure) to your new instance. This may happen as part of the upgrade, or it may not, depending on how you’re doing the upgrade (in-place versus migration, for example).
We’ve seen surprises crop up on the migrations, where the basic art of moving to a new release (or bigger configuration, or…) went really smoothly, only to be tripped up by missed details that really added up to painful lessons learned.
