IT Challenges of the Mergers, Movers and Shakers – Part 2

The art of a successful merger, move or acquisition – knowing your IT estate!

In Part 1 of this three-part blog I shared several life experiences. Some of them related to physical relocations and others related to acquisitions, whether that is a business acquiring another business or an incoming Head of IT acquiring a legacy infrastructure. In this part I am going to look at what can be done to avoid these situations. As I mentioned in Part 1, it starts with gathering information.

How you gather the detail will depend on how your current services are delivered. Larger organisations tend to have their user communities in tight control and know exactly what every user has access to and what they need systems wise to do their job. Small to medium sized businesses may not have this information and if they do not have this available to them from their central systems then the only method available to them may be to gather the information manually. In any case, it is always useful to gather information from the user community to find out what they their experience is really like. If I had just listened to the IT team in the 90 minute login scenario in Part 1 I would have assumed everything was working just fine.

“…I still come across applications that are not WAN friendly and require special attention.”

Smaller organisations or smaller offices in large organisations where there is no specific desktop management strategy may have users that have decided to do their own thing. Although this is relatively rare in commercial organisations with appropriate end point security controls, it is still safer to assume nothing.

This is also a good time to ensure the applications delivered to the users are working as efficiently as you believe and these are enabling a productive working environment. This is particularly important for remote offices on the end of WAN or internet VPN links. Also, it is possible the application worked well when first deployed but due to other changes or an increase in traffic it no longer works as expected. This is fairly common, and it is not always business traffic that causes the slow down.

While on this subject it is important to note that if you are relocating a group of people from head office out to an outlying office there may be additional technical challenges. Users accessing applications via the LAN in head office may not enjoy the same experience when they are in a remote office and the application is delivered across a WAN. If this is going to be a problem expectations need to be set. I am amazed that in our time of global networking I still come across applications that are not WAN friendly because they are bandwidth hungry or they have unrealistic latency requirements. I have taken these issues up with software developers in the past and it usually stems from the assumption that high speed services are available everywhere. This is far from reality even in some areas of large cities, but I am not climbing on my soap box today.

“I have experienced the problems of duplicate patching spreadsheets far too many times…”

If you do not have any inherent methods of gathering user information via your systems a simple spreadsheet may suffice. I created one for a customer earlier this year and it has been in popular demand ever since. It simply comprises rows of users and columns of applications. The users are asked put a comment under the systems they use saying what they use them for. You could also ask what their experience is like on a scale of one to five.

In addition to this gather as much information from your systems as you can. When combined with the information you have from your user community you will have a very good idea as to what you have to move and from that the implications of moving the users.

Next on the list is a full cabling infrastructure audit. In the absence of any formal system to record this information a spreadsheet will do the job as long as it is tightly controlled. I have experienced the problems of duplicate patching spreadsheets far too many times, it usually results in the costly exercise of having to completely audit the infrastructure again. I have seen this happen in the same installation several times in as many months.

“…many organisations have cabled outlets patched through to switch ports with access to all areas and never consider the risks.”

A cable audit is the ideal time to remove any patch cables that are not actually doing anything. In turn you will identify free switch ports and this may even prevent you from ordering more switches than you need. It is obviously better to remove patch cords as users move or leave but in many organisations this just doesn’t happen. I have seen many organisations – large and small, over-ordering switches because a prior ‘audit’ was simply a count of the switch ports with patch cables connected rather than identifying those with users attached.

Some may say the cost of the audit far exceeds the cost of the additional switches. But, this isn’t just about switch ports, it is also a potential information security risk when spare switch ports are patched through to wall outlets. It is for this reason that I believe a well installed and properly configured wireless network is just as secure, if not more secure, than the average wired network.

We typically make users go through several layers of authentication before allowing them access to systems from a wireless network and even then we may limit users accessing from the wireless to a subset of systems to reduce our security exposure. In contrast, many organisations have cabled outlets patched through to switch ports with access to all areas and never consider the risks.

As part of the infrastructure audit the latest configuration of every item of active equipment should also be obtained. The only real way of ensuring you have the current configuration is to capture it from the running equipment. Combined with this you need a strict change management process to ensure the copy of the configuration is maintained and it always current. If you do not implement a change management process it is the equivalent to having multiple copies of the cabling infrastructure spreadsheet, you will be forever capturing and auditing the configuration rather than managing change before the event.

“…plan a time when you can disable the lines from the script and wait for someone to shout.”

This is also a good time to check the switch ports for errors. If there are any errors noted make sure they are still current and incrementing. If they are stable they could be historical errors relating to a problem that has already been resolved.

Having captured all of the switch configurations you need to turn your attention to the routers. Capture and analyse all router configurations to identify any items in the configuration script you cannot account for. In particular, static routers, access control lists and remote configuration access. If you cannot account for any element of the configuration script your last resort may be to plan a time when you can disable the lines from the script and wait for someone to shout.

Lastly, we need to look at the firewalls. Capture the configurations and analyse the script to make sure you can account for every line, especially access rules. As with the router analysis, if there are lines of script you cannot account for you may need to disable them and wait for a complaint. But, above all, make it an absolute requirement for firewall rules to be requested by a formal change control process with appropriate sign off.

In the next and final part of this three-part blog I look at other aspects of a successful merger, move and acquisition including preparing for every eventuality.