Metrics for sunsetting systems

Really, these are similar metrics to what you would use to choose systems- except they’re often on the tail end of a choice made years ago.

I frequently see multiple systems run in parallel that really should be integrated (e.g., why would one have separate time and access cards?).  If you’re going to choose between systems, score them both and compare their relative risks and benefits.

This is a good time to read my previous post about sunk cost bias and risk adjustment.

I propose the following categories and considerations for evaluating systems for sunset:

  • Longevity
    • How long do you expect to need the system?
    • What would you do if you had to replace the system?
      • What’s the horizon on the subsystems? (e.g., if it only runs on SPARC, it’s probably time to look at sunsetting it.)
      • What if the vendor goes out of business?
      • What if there’s some horrific reliability or security problem and you had to take it down?
    • Is there any reason you would have to upgrade or modify the system in the foreseeable future to meet some need?  If so, what’s the cost and associated risk?
  • Data Synergy
    • Does the system tie to your strategic data goals?
    • How easy is it to import, export, back up, and manipulate data stored in the system?
    • Is the system tied to a core competence? (e.g., if your main customer CRM is very siloed, that probably matters a lot more than if your timecard system is).
  • Finance and Risk
    • Operating and maintenance costs.  Don’t forget that periodic downtime has some associated cost, and it’s really not acceptable for any system to be down for, say, 6 hours every night.
    • Patch intervals, speed of patch issuance, difficulty, likelihood of breakage.
    • How does the system score for PCI and other security frameworks?
    • Does the system integrate nicely with both your core systems and your customers’?
    • Does the system support accretive data?