Data Centers

Use case for older software: Easier, thinner, and quicker

When it comes to working with software, sometimes it just makes sense to use older supporting tools. IT pro Rick Vanover explains the pros and cons of consciously selecting older software titles for certain situations.

We live in a world of connected pieces of software that rely on many different pieces. Any given piece of functionality in the form of a software application can require an operating system, a database engine, browser functionality and more. Depending on the requirements, this can be a lot of supporting stuff just to get to run one piece of software.

Recently, I was discussing a test system for a piece of software and the question came up to build the test piece of software on a Windows Server 2003 R2 or Windows Server 2008 R2 system. My presumption was to use Windows Server 2008 R2, but the request was to use Windows Server 2003 R2. The reason was not for anything technical or dependency-related, but simply that things are easier on Windows Server 2003.

While I am generally pushing to use the latest and greatest for everything, I stopped and thought about this for a moment. If the software in question is supported on any modern operating system and brings the requisite functionality, does it really matter if the latest and greatest is used? The comment that the task is easier on Windows Server 2003 is simply true. While I really like Windows Server 2008 R2, it takes longer to do some things that I can do quickly in 2003.

The silver lining here is resource management. I work frequently with virtualized systems, and preserving precious system resources such as RAM is always in fashion. Windows Server 2003 R2 has a minimum amount of memory of 256 MB; Windows Server 2008 R2 has that minimum raised to 512 MB. While I frequently don't hover at the minimums, few people will disagree that Windows Server 2008 R2 requires more memory resources. Take storage into consideration, and Windows Server 2003 R2 will win that argument as well.

This poses the question that if the "solution" can function on older platforms, does that make sense? There are plenty of other factors to consider. These can include any cost considerations as well as the expected duration of the system. If the system will be around for a while, it may not make sense to enable an obsolete platform later.

This can be a passionate topic, do you ever consciously decide for the older platforms or related components when those don't matter? Share your comments below.


Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

Editor's Picks