How to document a strategy for upgrading commercial software

We haven’t upgraded our RDBMS or server OS for nearly a decade. Another mission-critical software package is nearing two decades old and has been unsupported by its vendor for much of that time. Some among our management (IT management, but also the people in suits) seem to think that this is a good thing–we saved tons of money by not buying the upgrades! Now a critical piece of software needs an upgrade, but the new version will not support the decade-old stuff. One aforementioned manager took on the lead of the project and started flipping switches, and now a handful of us are losing our hair trying to figure out how to upgrade everything at once with minimal down time. This is just one example of the rudderlessness of our IT ship.

In an effort to address this, a few of us are undertaking the creation of an IT strategic plan document in the hopes that we can get it adopted as part of the agency’s overall strategic plan. I’ve volunteered to try and assemble the “Software Lifecycle Management” (or something like that) section to address the problem noted above (with the brass tacks likely in a separate document from the strategic plan). Nearly all software vendors publish life cycles and deprecation plans for their products, and it’s easy enough to determine a “sweet spot” for each piece of software considering that info along with our organization’s needs. The tricky part (for me anyway) is putting the plan for each piece together into something more cohesive.

How can I document that desktop clients A,B,C… are dependent upon desktop OS X and RDBMS Y, which in turn depends on server OS Z, and then here’s how we keep all of them in their “sweet spots”? There must be books out there, but all my googling has only led me to stuff about the tactics of upgrading a single piece of software rather than the strategy for determining when to implement those tactics.