Part 1 Part 2

It’s not everyday that you find a company or IT department that keeps a structured and updated “update log” for their systems, let alone Sharepoint. Updating your software is as easy as clicking a few buttons and trusting that everything will work as advertised. And for the most part, application updates really do what they are supposed to without causing outages. With communities, blogs and wikis for just about every application in existence, developers find it much easier to distribute test builds to the masses and receive responses rather quickly. This translates to quicker bug fixes and an overall better experience for end-users. But this can also lead to an ultra-trusting mentality when it comes to updating your software with major upgrades and/or patches. It only takes one patch to create hours of work for you and your team to get the system back online when incompatibilities rear their ugly heads.

This three part article will aim to give you my thoughts for an effective update log for your Sharepoint servers.

NOTE: I’ve written this article with respect to Sharepoint specifically. It is part of a larger concept that could be incorporated into all LOB systems.

The first thing that we need to do is figure out where we should store our data. Depending on your needs and organizational size this may be a very simple setup, but it still helps to think it through first.

The table below summarizes a few pros and cons for 4 possible scenarios.

This is a pretty self-explanatory table, but I want to touch on one of these […]