Recently I encountered a situation with a client who wanted to upgrade a critical piece of software present in their infrastructure.
It was a classic thick client/server accounting application utilizing SQL Server on the backend. The organization considered this to be a legacy application, albeit one that was still key and in heavy use, but only within one department of a half-dozen people.
The client wanted to upgrade to the latest version of the application to take advantage of new features that the vendor had introduced in their latest release. They were also getting ready to do a hardware refresh with an switch from Windows XP to Windows 7.
There were several problems that I had to tackle alongside their in-house IT team:
- The installed version of the application was two versions behind the current version.
- The current version was itself scheduled to be replaced by a newer version within three months.
- The installed version only ran against SQL Server 2000.
- The current version only ran against SQL Server 2005 or 2008.
- The installed version ran on Windows 7, but not without breaking a feature that required a cumbersome workaround.
- The new features the client wanted were present in the current version, but they wanted to go with the "within three months" version.
- There was no direct upgrade path from the installed version to the "within three months" version.
- There was a direct upgrade path from the installed version to the current version, thankfully.
- No support contract or software maintenance agreement was in place with the vendor. In fact, the product had been bought out by another vendor!
The last item was the most surprising until I found out the reasoning. It was simply because this piece of software got lost within the organization. After a series of mergers and acquisitions, the department that used the application continued to do so without any issues. Any issues they encountered were minor and they were always able to get their work done. IT had performed software inventory audits periodically, but erroneously indicated that a newer version was installed.
Most of you who have been IT pros for awhile can see where this is going and are likely forming an upgrade path in your head already. That path includes a dreaded "double bounce" upgrade, from the installed version to an interim "current" version before landing on the final "within three months" desired version. Oh, and don't forget about migrating the database from SQL Server 2000 to 2008 alongside upgrading the thick client software on the desktop machines while the folks there are getting used to the new features and interface changes.
This sounds like an awful amount of work wrought with plenty of potential pitfalls. It would certainly be simpler to not do anything. Remember, the original application was running just fine, thank you very much.
After completing the work, I suggested to the client that we try to plan ahead so as to not be caught off-guard later on. I suggested that, with us on version X, when the vendor releases version Y, we take notice and spend some time examining what would be involved with moving to that version if desired. Then, when the vendor releases version Z, we plan to at least move to version Y to stay reasonably current.
It can be quite a challenge to follow a policy like this. IT teams are often overwhelmed with keeping pace with just their key vendors, let alone the smaller ones that supply an application used by only a few people. It can also be difficult to get a defined support policy from some vendors, especially smaller ones.
However, at some point in everyone's IT career, you will have to do an upgrade to a piece of software in a situation similar to this one. Try to avoid this. Try to stay reasonably current. It will save you from working long weekend hours, or at least cut down on them!