Skip to content

Approach to installing software and applying software product updates?

by on October 27, 2011

The planning and approach to rolling out new software versions and product updates are a constant challenge in almost every organization.  Organizations struggle with the right mix of when to do the upgrades, what specific versions to install, and when to apply ongoing maintenance.  All organizations specific release plans are unique, but all face the same challenges and questions.  This blog is going to focus at a high level of the two main areas  (1) New Software/Upgrades and  (2) Maintenance/Fix Packs/Product Updates.  Future blogs can go into these individually, break them out further, and go into details of the approach and challenges  of the specific area.

New Software / Upgrades:

This can be newly purchased software (even factoring into the decision to purchase) or performing upgrades of major product releases.  What versions and when to install are critical decisions.  To keep things simple, I am just going to break the approach into two main groups:  (1) Early adopters and (2) Mainstream.  The early adopters always want the latest and greatest versions.  The reasons for these can be because they are very technology focused and always want the latest and greatest “cool” features or because their specific implementation or business/technology needs require these features.  The mainstream groups typically only want to run on proven and reliable technology.  These mainstream organizations do not want to “test” new products or upgrades for the product vendors and typically not only want the product to be stable (i.e. a few versions have already been released), but for the specific version to have already released a few product updates to fix early issues found by the early adopters or product vendors own testing team.   There are additional specific classifications that organizations can fall into, but these in some form or variation cover over 80%.

Maintenance/Fix Packs/Product Updates:

Once you have your product installed and running in production, you know face the bigger ongoing challenges of when to apply maintenance, product fixes, and general product updates (this is similar to product upgrades, but that is covered in section above).  Similar to the above, the early adopters may be inclined to install these very quickly to make sure they are staying current as well as may have been the ones to identify (or notice) some of the early bugs in the software.  However, the mainstream group now tends to get split up a little more now that their software is in production.  We can dedicate entire blogs, white papers, or meetings to discuss the approaches in detail, but here I just want to mention a few main approaches:

1.  Install latest immediately (i.e. as soon as you can schedule down-time of specific server – this is helped if you have an HA environment where you can have no production down time)

2.  Install latest maintenance as soon as possible (usually during regular monthly maintainance of servers or other windows organizations have)

3.  Install only when required

Typically, #1 is recommended only if #3 is true, but all organizations are different and factors such as staff, project schedules, and specific products may weigh into the decision to always be running on the latest maintenance as soon as possible.

Most organizations fall somewhere between #2 and #3.  Again, this has a lot to do with how the organization is structured and how software products are deployed (i.e. are we talking about a handful of servers or we talking about performing the upgrades over 100’s of physical or virtual servers).

#2 provides some challenges because if you have a large infrastructure, you will be constantly applying these maintenances and possibly risking your production environments availability.  This can also be for little or no value from a product feature perspective and may be for maintenances that are not relevant for how you are using the software.  However, the main advantage here is that you always have the latest fixes supplied by the product vendor which limits your exposure to production defects in your environment.  You are also at the latest version which many product vendors will require before they provide any support to you if issues are found in your environment.

#3 is almost a swap of the challenges and benefits of #2.  One philosophy here is if it isn’t broken, why fix it.  This does hold true in many cases, however, as I mentioned above, if you are required to call the software vendor for support, they may require you to perform the upgrade before they help you further.  This can be time-consuming right as you are under pressure from your business and users during an outage related to the software product issue.

We have helped many organizations with these types of approaches and they are all different.  Typically, they fall somewhere between #2 and #3 above and an organizations specific environment, requirements, and goals provide the information required to recommend and implement an effective release plan.



From → General IT

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: