T-SQL Tuesday this month is all about upgrades, so here are a few more thoughts on the topic. Let’s start with Reitse Eskens:
Things change when you’re working with a lot of data or when you’re trying to use SQL Server to the max. At some point you’ll see new features that will support your workload or add security for your data. Here are the steps I’d take to evaluate new versions.
Todd Kleinhans tells a horror story with a happy ending:
I had just been laid off for the first time in my life from a dot com. I was a classic ASP web developer, a junior development DBA, and I knew Access and FileMaker Pro. Interviewed and got hired on as a contractor to help with Access and ASP.
Before me, a local consulting company was retained to help them with the migration from Access to SQL Server. It was a disaster.
Rob Farley thinks about ways to make the upgrade process smoother:
I don’t envy application vendors who don’t have a strong DevOps story. They need to get it in place so that they can scale, but it doesn’t happen overnight. The road to good deployment practice is long and is threatened by all kinds of things. Code coverage is rarely complete, and problems seem to find those places that don’t have good testing in place yet (typically because problems are avoided in the areas that do have good testing). All this is so much easier when a project is starting from scratch, and not the culmination of a decade or more of development needing to be compatible with the last four versions of SQL Server and Windows.