Over the last 6 months we have had a few clients want to delay upgrading to the latest version of WordPress. They didn’t see any urgency to upgrade because there were no immediate security concerns addressed in the update that affected their site.

I can certainly understand this thinking. When upgrading you need to spend time re-testing custom functionality, perhaps take the site down briefly, address any post-upgrade issues that might have snuck through the initial QA process; when the site is reasonably complex, it takes time. I can understand this thinking, but it’s wrong.

Any time you are running an application in production, you need to keep yourself in position to apply security patches immediately upon release. For WordPress, this means always running the latest version.

While the current new release may not include any security patches, it’s still important to upgrade quickly. You never know when a new security patch may be released. With WordPress, these patches are available as new versions (3.2.x) to the most recent version (3.2). If you delay upgrading because there were no security issues addressed in a specific release, you can easily find yourself in a position where you need to urgently upgrade through several releases in order to apply the security patches in the latest release.

That kind of fire drill is a recipe for trouble and sometimes it just isn’t feasible. If this happens, you may end up running code with known vulnerabilities for several days while you get everything in place and tested to push the upgrade to your live site. That’s a bad place to be.

You want to be performing upgrading to major feature releases on your schedule. This allows the upgrade process to be organized, well-tested and (hopefully) without incident. You also benefit from smaller functional deltas – fewer changes to test against makes the testing easier.

Performing upgrades as soon as they are available is the best way to keep your site secure and running smoothly. Do it.