Skip to Content

Retirement takes planning AND implementing.

I went to a retirement party last week.  I pictured we would be sitting outside on the deck where hors d’oeuvres would be served with the fanciful summer cocktail menu.  But alas, it was dull and dreary in the basement where co-workers had assembled to bid their adieu.  The recipient of the send-off had served the company unfailingly for over 30 years, but had indeed found a storied skill-set had been replaced by a better connected, shinier, faster face.  The retirement had not really been planned, it was more like someone created a flash mob at the behest of the auditors.  Not the type of orderly and grateful departure one might expect at the end of such a long-term service engagement.

The future is here, broadcast in the bright Technicolor of our youth, with new sounding names and labels like Nexus of Forces, Big Data, Mobile, Social Engagement, the Internet of Things and of course, the ubiquitous CLOUD.  In the rush to adopt the latest and greatest technological innovation to preserve a competitive edge, we are forgetting about the seasoned veterans and the secrets they keep.

Application retirement, or decommissioning, is about managing the safe passage of data and documents from online or archived databases in old systems that are no longer used for current business processing.  The information must be retrieved from the retiring system and migrated to a new location, where it can be accessed and managed as necessary. Migration offers more cost effective storage options.  The retirement of the application eliminates the cost of keeping a fully operational system up and running to simply serve the purpose of providing an access point to the data when that auditor rings your phone.  There is also a risk in keeping these systems around: old technology is, well, old.  The aging process is not graceful for many of these legacy systems, and they tend to break down at the most inopportune times.

Consider the case where a global manufacturer faces a product liability issue that requires accessing years-old data.  The fellow who had been entrusted to maintain that database, with the checkered sport coat and too-wide tie, has recently retired himself.  Once the code is cracked and the system is finally accessed, it is determined that the disk with critical data has actually failed.  A painful litigious process just got a whole lot worse. 

Legacy decommissioning is a task that never seems critical enough to get the nod from the budget allocators until it’s too late.  Part of the problem is that it is not well-enough understood to make the business case in words or numbers.  But it should be on every IT/data management roadmap to ensure your organization remains compliant and protected.  Living with the risk should not be the strategy for these systems.  Sipping fancy iced drinks knowing critical data and documents are accessible at any time sounds a whole lot better.  

1 Comment
You must be Logged on to comment or reply to a post.
  • Retirement  –  Right on.  I started reading this & thought off topic at first  but it was very interesting.  SAP Legacy System Decommissioning and data expiration is not being taken seriously until there is trouble( lawsuits, fines, time critical Audits).  I don’t understand how so many companies are not Compliant to their own retention policies or laws of the land.   Software is needed to help expire and destroy data but most seem to have their blinders on.  It may not be easy to destroy data & keep only what is needed but worthwhile.     I’m going back to have one of those cocktails you referred to Brian.    Thanks.  Bill