Keep the data, toss the code
Managing application portfolios following mergers and acquisitions.
IT has become a critical enabler for delivering the synergies for a merger or acquisition. A successful system integration based on a single set of processes and applications often implies a smaller, and hence more efficient, organisation. The sooner this goal can be achieved, the sooner the financial benefits kick in.
So, if you find yourself in this situation, what is the best way to rapidly rationalise your application estate and decide on your target application environment?
When two organisations in the same industry merge, they often have a similar set of systems. The resulting organisation then inherits a set of duplicate systems for each functional area. The obvious solution to integration is to select one of the duplicate systems as the target application and to migrate the other system’s data to this application. In general, the target application will need some development to move functionality that was unique in the legacy system. This migration approach is in many cases faster and lower risk vs. developing a completely new application: (i) rolling out an existing system will be quicker, (ii) using an existing system reduces training effort and (iii) the solution will be automatically accepted by those senior stakeholders selecting the target application.
However, this approach may not be the right solution in all circumstances. For example, it may result in a longer time-to-market for new strategic functionality as resources are focussed on the migration instead. Therefore, some companies choose to develop a new system that will replace both legacy systems if the strategic benefits are strong enough.
How should you decide which one of the duplicate systems becomes the target application?
In some cases, the selection of the target application may be trivial: An acquirer may have reshaped its own IT platform to rapidly integrate smaller organisations. Or one of two merging companies may have a flexible, streamlined IT – and this may even be one of the drivers that made the deal attractive in the first place.
However, in general, the selection process will not be straightforward. In that case, define a set of criteria to evaluate the different options including: ability to enable business drivers for the merger, strategic fit, functionality, scalability, integration complexity, cost, time-to-market, project risk, training effort, vendor profile, and stakeholder preference. Strategic fit may include alignment to an overall IT strategy, for example: the decision to standardise on .NET applications or implement cloud based application for a rapidly expanding business.
A long, detailed, and expensive evaluation process is often not the correct approach for selecting the target application. Not only will you lose valuable time, but the process will seldom be objective as different stakeholder groups will defend their interests. Instead, drive fast, unbiased decisions to remove the uncertainty and to focus the organisation on how to make the transition work.