Shadow IT Service Transition

Recently, I received a request to give some tips on Service Transition when dealing with Shadow IT. Essentially, there are situations, where an IT system is not supported by the company's IT. Why that happens is a subject for another discussion. In this post, let's examine what to do about it.

Coming Out

Over time, the business department owning the system is likely to grow tired of supporting the IT system. It is, after all, a non-core activity. There might be some wannabe IT guys within that department, but once they move on, it turns out that there is nobody to replace them. Whatever the reasons, the company's IT is approached and asked to take the system over to support.

Due Diligence

The thing that needs to happen now is due diligence. The situation needs to be examined by the IT department on multiple levels:

  • Current support contracts with external vendors
  • Technology profile and potential training needs within the IT team
  • Available documentation
  • System stability, history of incidents and involvement of the vendors (likely to be obtained from saved emails and interviews with the current business owners or the vendor)
  • Staffing needs
After due diligence is done and you have all the data, you are ready to go to the next stage.

SLA and Support Model

In the simplest form, the service is transitioned to the responsibility of IT with little technical work. The main thing that needs to happen is setting up the company's ITSM tool. However, this is also the moment when SLA needs to be agreed. It is very important, because it sets clear expectations on both sides.

You need to ensure the users call the service desk from now on. They are not used to it in relation to this service. Keep that in mind and make sure the new process is clearly communicated in advance.

Lastly, you need to create a support model document, which will describe how each IT Service Management process will be handled for this service. It is an internal instruction for your IT teams. Initially, if it seems like an overkill, you can keep it simple, and just describe the Incident Management process. Draw a flowchart and put annotations on it. It is important to know who in IT is responsible for what in relation to this service. This document will tell you that.


Shadow IT is generally quite risky to the company, so reasonable effort should be made to eliminate it. However, if it is widespread, eliminating it all in a big bang could spread IT resources thin on multiple unreliable solutions. If due diligence shows multiple risk areas, might be better to maintain status quo and advocate launching a project intended to replace the unreliable system with a better one, this time with proper support of the IT department.


Post a Comment