App hoarding. The dark, unspoken secret. We’ve all done it. I logged on to a Windows 8 tablet I hadn’t used for quite some time, and I was so ashamed of myself. So much junk, so many free apps I downloaded, tried, and abandoned. Only recently have I begun steadfastly maintaining a “two screen” limit on iOS to try and keep the applications on my devices solely to those that I use regularly.

This isn’t new, mind you. Enterprises have been doing this for years. Sometimes the “application” is an Excel spreadsheet. Sometimes it’s an old database application, or some other piece of old code, owned by a developer who long since ran from the organization.

For a long time, like Microsoft and comprehensive security ahead of the Windows security push, customers could turn a blind eye to application proliferation. Like feral rabbits, one will lead to many, and if you don’t manage or cut them back, they get out of control. Unfortunately, many enterprise applications are borne out of short-term necessity, without a great period of design forethought. Just as unfortunately, nobody goes around every year and does an “application census” in most organizations to figure out which applications are dead, abandoned, unused, or worst of all – insecure or unsecurable.

A colleague today was telling me about an antivirus application from a major vendor that relies on Java. Terrifying. But that’s nothing. Java is still supported (how well supported is arguable). If your organization is of any significant size, you’ve got applications based around ancient versions of Microsoft Office, SQL Server, or other products and platforms that are likely long past their expiration date. No updates, no patches, nothing. Yet your organization depends on them, and likely has no security mitigation or migration story in play. With the current crop of vulnerabilities we’ve seen recently in Java, Flash, and Acrobat Reader, I’ve been growing increasingly concerned with how dependent so many organizations are upon all three, yet how laissez-faire they seem to be about eliminating or at least reducing their dependency upon all three.

On a similar note, as someone who helped ship Windows XP, I love how well it has stood the test of time. But it was not engineered for today’s world – from an always-on connection to the Internet to the threat vectors being thrown at it and the software running on it.

It concerns me that so many organizations aren’t cognizant of what software (operating systems, platforms, and applications) are running in their organizations. They talk big of cloud, and how it’s better that they run the software on their premises. Yet they’re running old, unpatched software, often with known, never-to-be-patched vulnerabilities, and no plan to consolidate applications and remove dead, unsupported operating systems, platforms, and applications. It’s the equivalent of every enterprise having a bunch of storage units full of random crap you keep around because “someone might need it someday”.

Microsoft has been beating a drum about Windows XP – if you look at it closely, it sounds more like a marketing message. But whether you view it as that or not, and whether Windows 7, Windows 8, or something else entirely is in the cards for you, your business has barely one year to get off of Windows XP (April 8, 2014). We’ve heard from some customers that they have heard of custom support options after that time, but they are on a per-desktop basis, and the adage, “if you have to ask, you probably can’t afford it” appears to apply quite well. Windows XP (officially at death’s door) and Office 2003, also very widely used still, both pass into the great beyond on that same day.

Whether it is Windows XP, Office 2003, more porous (hard or impossible to patch) platform components, or custom applications on top of them, it’s imperative that organizations start managing and monitoring – and deprecating/discontinuing – applications that rely on dead software to exist. They’re putting your organization at risk. For me, there are two takes to this – cut back the applications you already have, and more importantly, carefully regulate how you build and deploy new ones, with a keen eye on the support lifecycle – and the patchability/supportability – of the OS, runtimes, and applications that you build upon. Applications can seem quick and easy to build on a whim. But like a puppy, or perhaps even more like a parrot, applications aren’t free to build or maintain. They are a long-term commitment.