If you’re anything like us, you’ve got more than enough work to keep your team busy. The appetite for web sites and applications continues to grow at a frenetic pace, and the ministry teams we support have no shortage of great ideas. And, of course, we all love to work on projects that come with new challenges, cutting-edge technologies, and high impact. Yet, in the midst of all of this activity, we cannot neglect the technology infrastructure that allows us to provide these great services to our ministries and their audience.
One particular challenge that we’ve been discussing lately is upgrades. There are many different schools of thought on this one - some could be considered “early adopters”, choosing to upgrade their systems with every new release. This is attractive in that you’re always up-to-date should any problems with your infrastructure arise, and you get the new features as soon as they come out. On the other end of the spectrum, there are those that never upgrade unless they encounter a problem - “if it ain’t broke, don’t fix it.”
One of the by-products of our organization’s strategy to be a “House of Brands” is that we have a lot of different sites running on a variety of platforms, so we’ve recently started putting together a strategy for how and when to upgrade our systems. This includes the following, to name a few:
- Operating Systems for our web servers and database servers (Red Hat Linux and Windows Server)
- Database Systems (MySQL and Microsoft SQL)
- WordPress, WordPress MU, and Expression Engine content management systems
- Church Management Systems
- Java and .NET
- jQuery
We’re more than a little overdue to implement a proactive strategy around how we want to keep these systems up-to-date, but we are working on it and getting better. Whether you have one site or many to manage, it is prudent to sit down and figure out what strategy fits your organization best.

February 15th, 2010 at 12:07 pm
Our upgrade strategy is:
* Desktops & Notebooks: 25%/year
* Software (NOS, OS, apps): Keep current, but generally wait for the first service pack to avoid spending time addressing issues due to poor code
* User Training– the forgotten system component! Aim for monthly short sessions that users walk away feeling like they can’t afford to miss