Decommissioning stuff

I’ve been thinking about decommissioning IT systems, mainly because I’ve been asked to turn a few systems off at the place where I work. I’ve done this a few times before and it’s never as easy as you might think. Removing 80% of the functional value of a system and 80% of the users is the easy bit. The last 20% of both is usually difficult both technically and politically.

So a way of making the process of decommissioning an IT system more deterministic would be a good thing. Before I start trying to turn a system off I’d like to know what my chances of succeeding are.


One thing I think you need to establish at the start is who the stakeholders are. For systems that have been around for a long time this can be surprisingly hard. These systems are often part of the furniture to the extent that users don’t even realise they are using the system, it’s just how they naturally do their jobs. An old system may have no formal governance because it was introduced at a time when the control environment was not as far-reaching as it is today. All this can make it hard to find out who is affected by the decision to decommission the system.

What you would have ideally is a clear ownership of the system by the business, with a named owner and some sort of representation from each part of the business that uses the system. From the technical side you would have a named IT owner who understands the dependencies that other systems have on your target system.

If these things don’t exist for your target system then you are probably going to have to invent them. Because the first thing you need is a statement of the system’s functional value from its users – if you can’t get that then you should probably just turn it off anyway and see who screams. Armed with a statement of value and an analysis of functional dependencies from your IT owner, you at least know what work needs to take place to make conditions acceptable to turn off the system.

The needs of the many outweigh the needs of the few

A timeless story of innovation is that a functional gap has been plugged by a tactical system. The system is highly specific to the functional niche it inhabits and over time it comes to do everything the users want and they have learned to operate it efficiently. Then along comes Strategy, lumbering through the IT undergrowth like a tyrannosaurus. Whole swathes of tactical applications are replaced by one strategic system because it consolidates costs and organisation into something that senior management can understand.

The strategic system is specified on the basis of functionality that is required by the user. Inevitably you are proposing to replace a tactical system that does everything the user wants with a strategic system that only does what they need. The cost distribution of the new system will have been worked out “fairly” by accountants. Which often means that your longest-standing users end up paying more for a system that does less.

It can be a hard sell. Fortunately you have senior management on your side and if the users don’t like it they can do their complaining from the deserted outpost they are transferred to.

Data retention

Your users are going to ask for all the data in the system to be retained indefinitely, and made available on line for ad hoc queries. Ignore them, they always say this. In my experience of having acceded to user requests like this, the data is never looked at after the end of the first month of the new system. Suggest a rational data retention policy and a straightforward migration of any applicable to data to the replacement system (if any). Be aware of legal and regulatory requirements.


I think the steps towards making a decision to decommission a system are these:

  1. Establish a competent governance framework for the system.
  2. Get a statement of the functional value of the system from its business owners
  3. Get an analysis of the dependencies on the system from its IT owner
  4. Get a signed agreement that certain named projects will replace any valuable functionality
  5. Agree a rational data retention and migration policy
  6. Get a signed agreement that the system can be turned off subject to the aforementioned project deliverables and data policy.
  7. Plan the decommissioning like any other change using your best practice Change Management procedures.

Turning IT systems off is a good thing. I think it signifies that an IT organisation is mature but not senile. If understand your system landscape well enough to be able to say with confidence that this system is no longer required then you are doing something right. If you can actually execute that decision then it also reflects well on your relationship with your customers.


0 Responses to “Decommissioning stuff”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


This is not a riot

RSS What Dominic is doing

  • An error has occurred; the feed is probably down. Try again later.

Share me

Add to Technorati Favorites

Dominic's photographs

RSS My stubbornly unread reading list

  • An error has occurred; the feed is probably down. Try again later.

%d bloggers like this: