5 Steps Towards Successful Post- Merger Integration: Part Two-IT Due Diligence

Read our article on the 5 Steps Towards Successful Post- Merger Integration: Part Two-IT Due Diligence

IT Due Diligence – a bit boring , isn’t it?

It sounds incredibly dry, but if you’ve worked in enterprise IT for a while IT due diligence is an opportunity get to draw from your past experience, both in tech and management, and produce a deliverable that is a crucial component to company growth – the beginnings of a successful M&A transformation and realisation of return of investment (ROI) on the deal. It is far more rewarding professionally than systems implementation.

What is IT Due Diligence?

In the context of post-merger integration, IT due diligence is the need to locate and understand the technology estate, including key intellectual property.  Easier said than done!  Corporate technology estates evolve over decades, and you are expected to inspect and bring everything to the surface within months.  Read that again – entire corporate estates that took years to build, to be fully assessed within months.

Imagine buying a house or car and before being able to use it having take it apart, find all the associated components and how they connect, and then produce a meaningful and comprehensive report within a short period of time. Also with the added pressure of knowing that if your report is incorrect, the car might break down, or the house collapse.  Okay, that’s a little dramatic, but you get the point.

Technology due diligence as part of an M&A deal can be make or break.  If the team misses even 5% of the information, the entire project approach, associated resources and budget may have to be reassessed. You can imagine how going cap-in-hand to the board will go down with the C-suite and your own team.

What should you be looking from a due diligence exercise?

Given enough time and experienced talent, every post-merger integration team should be able to find services, applications, hardware etc.  That’s a given. Therefore, the main deliverable from this phase of M&A transformation is credibility:

- You need access to systems and sensitive information
- You need to start shaping how this information is going to construct the transformation
- You need to persuade the project board that you have a complete Service Catalogue
- You need to demonstrate to two or more technical teams that you know what you are doing

All of this which takes enterprise experience, customer-facing consulting skills, and the ability to sense when things don’t sound right.  If you get through the due diligence exercise you’ll have certainly built rapport and credibility across the teams and across many businesses, and possibly in many cultures and countries.

How does IT due diligence differ for post-merger integration?

On the surface, it may seem like the due diligence effort is not much different to a ‘“normal’” enterprise transformation programme, such as an enterprise application consolidation, or enterprise desktop refresh, but the following factors amplify the risks:

- Multi-party / multi-company technology teams
- Differing cultures and technology policies
- The impact of different policies and how technology is implemented at either firm
- The ‘entry requirements’ across firms – what is acceptable at one may not be at another
- Software is potentially being moved to another company
- The financial impact of transferring or novating software licensing,
- Delays caused by technical unknowns or vendor support and flexibility.

In addition, it is critical to understand the systems and whether these are ‘acceptable’ in the new world IT environment; for example, the acquisition may be running a critical application on what is deemed an unacceptable configuration or platform in the new firm.

How does IT due diligence differ for post-merger integration?

It is almost certain that a high-level view of systems will already be understood, as this would formed part of the M&A deal, but this may only cover a percentage of the application estate.  Whilst a company may have a small number of these ‘above the line’ systems, they are likely to be running hundreds or even thousands of applications.  These need to be assessed and put into the plan.

During the ‘Examine’ phase of the managed M&A you will need to:

- Interview IT stakeholders to gather key information
- Develop a detailed CMDB of assets
- Develop a project-specific catalogue of services that can be used to plan and manage the transition
- Create and manage the list of support contracts
- Create a company-wide software inventory and ensure the licensing implications are understood
- Record the IT finances and contracts

Regardless of effort there will be some surprises on the way, but it is imperative to provide carry out a quality assessment, given limited time and resources.

Access and credibility Challenges

At the early stages most people are sizing-up whether you’ve done anything like this before.  It makes sense; their systems (and careers!) are in your hands.  In some cases, We have been asked outright (in an aggressive tone) “Have you done this before?”

But here’s the trick – document the previous project(s), the primary challenges and the lessons learned in a simple, easy-to-read table.  This becomes an easy to reference card that is useful for the team you are starting to work with, but also helps you to keep an eye on things –  they may end up on your ‘lessons learned’ list if they don’t behave!

How does IT due diligence differ for post-merger integration?

Using the information you have gathered so far, you should be able to create a stakeholder map of all the relevant people, their relationships, and how they will help the M&A project.  This differs from the  organisational hierarchy, as it is a more pragmatic overview of the people who will be useful. In regard each stakeholder, you need to establish:

- How they can help you
- Their key interest
- Their fear
- What’s in it for them

Presenting the map to the client will show how thorough you are (building more credibility), and for yourself it’s a useful reference when things become difficult.


The obligatory team-wide workshops will inevitably commence.  In our opinion, they are a major waste of time.   Even before ‘“agile’” was a buzzword we’d get really frustrated about the time wasted in team-wide workshops.  We much prefer setting up smaller meetings and creating mini task-forces to be responsible for.

For global teams there’s a benefit for to everyone seeing the whites of each other’s eyes, but maybe consider off- site socials.

A common mistake is the feeling that the entire environment is so complex that it necessitates an inordinate number of workshops, and a need to invite all the key people from both teams – imagine the waste.  Most people won’t participate, and there’s no major benefit of being aware of the historical decisions made along the way.   It is also very common for skilled technical people not to attend, so the workshops are often ineffective.

Regardless, this is one of the first point in time when you will see who will collaborate and help versus who will become an obstacle.  So it is worthwhile having a workshop or two, but resist the temptation to have too many.

Benchmarking challenges

As part of the IT team from the ‘other side’ you are likely to be the first person representing the buy-side firm that they will speak with.

You will immediately face a conflict, as you need to speak with key stakeholders within the firm to obtain confidential information about their business.  Firstly, you need to determine who those people are, and second, you will need to demonstrate some credibility, explaining that you have done this before, in order to gain and share vital information.

CMDB challenges

It is common for broad-brush estimations and assumptions to be made about an IT environment due to the size of the target firm, but beware. In order to deliver a successful project, you need an accurate inventory.  

Sometimes the solution is not technical, it is meeting the right person and asking them the right question. In one experience I started work at an SMB of 200 employees – the client had assumed it would take a couple of months to integrate them, as they were expected to have 40-50 servers. On the first day of deep interrogation it became obvious this assumption was incorrect – the company had over 3,000 servers to be integrated, which obviously had a major impact on timeline and costs.  

It is well- known that without a Configuration Management Database (‘CMDB’) providing an accurate inventory, it is impossible to plan accurately.  Without truly knowing what’s there, you cannot establish what to do with the systems and, more importantly, who you need to work with to ensure they are transferred correctly into the new environment.  This is the same for all IT projects, but the difference with an M&A is that it is a company-wide concern.  

Worse, if you cannot determine what’s there, you will bee unaware of your the risks you are exposed to – for instance, will the systems from at the target firm meet your company’s security requirements? Is some remediation work required? Are there legacy systems that are on their last legs?  It is very common for projects to be stopped mid-flight, and come to a complete standstill, due to some disagreement that has occurred due to an inaccurate CMDB.

If you would like to know more about M&A challenges - contact the team at Beyond Migration at info@beyondmigration.com