Analyzing an Upgrade after the fact

We had a major upgrade to our main application recently, so I thought I would share some of the “thoughts from the aftermath.”

The good:  We gave the application back to the business 1/2 of a business day earlier than expected.   Win.

The bad:  We were hoping to give it back a full day earlier

The ugly: we wasted a full day having to rollback and start over

Some lessons learned:

  • Full backups ahead of time are a great idea – check
  • Restore scripts for those backups are a great idea – check
  • Using SQLCMD to apply vendor .sql files is a great idea – check
  • Forgetting the -I parameter in SQLCMD is a bad idea (not -i, but -I for Quoted Identifiers, which is false by deafult in SQLCMD, but True in SSMS)
  • Not having a full setup lab environment to test everything – bad
  • Using the default settings in SSDT Schema Compare – bad
  • Re-ordering column order in tables for cosmetic reasons – bad (this one is on the vendor…we had to re-write some code that broke)
  • KrispyKreme donuts in the war room followed by a huge box of cupcakes – bad.  Didn’t affect the upgrade but I ate too much 😉

Those are the big items.

This post inspired by Tim Mitchell‘s post today : Studying Failures

Feel free to share your deployment/upgrade brilliance or derp moments in the comments below.



Leave a Comment

Sign up for our Newsletter

%d bloggers like this: