Every M&A transaction contains an implicit IT integration programme. It is rarely scoped properly during due diligence, almost never funded to the level the work requires, and consistently delivered later than the business expects. After leading multiple banking mergers and post-merger integration programmes across Europe, the patterns are clear enough to describe with some confidence: where the time goes, where the money goes, and what the plans that actually work look like.
Why Integration Takes Longer Than Anyone Plans
The planning failure in post-merger IT integration is not, in most cases, a failure of project management. It is a failure of discovery. The time estimates produced during due diligence are based on what is known about the target organisation's technology estate — which is, almost invariably, significantly less than the reality. Due diligence timelines are short. IT landscapes are complex. The combination produces plans that are optimistic in ways that only become visible once the integration programme is underway and the full complexity of the target estate is understood.
Three specific discoveries consistently extend integration timelines beyond initial estimates.
The undocumented integration estate. The target organisation's systems are connected to each other — and to external parties — through interfaces that are partially or wholly undocumented. These interfaces were built incrementally over years, often by people who are no longer at the organisation, and they exist in configurations that differ from what the documentation says. Mapping them takes time. Remediating them in the context of a platform change takes more time. And doing this work under deadline pressure, in a live production environment, introduces risk that is very hard to manage.
The data quality problems. Merging two organisations' data — customer records, account data, product configurations, counterparty information — surfaces quality problems in both estates that were not visible before the merge was attempted. Data that was adequate when it only had to support one organisation's processes frequently fails validation when it has to conform to the combined organisation's standards. Cleansing it is slow, manual work that cannot be significantly accelerated without introducing new errors.
The regulatory requirements that were not anticipated. Banking mergers in regulated markets trigger regulatory obligations that are not always fully anticipated at the planning stage. Change-of-control notifications, updated entity structures in regulatory reporting, changes to resolution planning — each has IT implications that may not have been scoped in the original integration plan. In the German banking market specifically, BaFin's requirements for operational continuity during integration add a layer of planning and governance that programmes coming from other jurisdictions consistently underestimate.
"The integration plan produced during due diligence is a hypothesis. The actual programme begins when you understand what you are actually dealing with — which is typically three to six months into execution."
Where the Money Goes
Post-merger IT integration programmes consistently exceed their initial budgets. Understanding where the overrun occurs is more useful than accepting it as an inevitable feature of merger programmes.
Parallel running costs more and lasts longer than planned. Running two technology estates simultaneously — maintaining both organisations' systems in production while the integration is being built and tested — is expensive. The cost is usually estimated against the planned integration timeline. When the timeline extends — as it almost always does — the parallel running costs extend with it. A programme planned for eighteen months of parallel running that takes twenty-four months costs a third more in parallel running costs alone, before any other budget variation is considered.
People costs are underestimated. Integration programmes require people who understand the systems being integrated — people who, by definition, come from the existing organisations and have operational responsibilities that do not disappear because a merger has been announced. The cost of backfilling operational roles while subject-matter experts contribute to the integration programme, and the cost of retaining key people who have options to leave during the uncertainty of a merger, are both consistently underestimated in integration budgets.
Remediation is not in the plan. The data quality issues, the undocumented interfaces, and the regulatory requirements described above all require remediation — work that was not in the original scope because it was not known about when the scope was defined. That remediation has to be funded from somewhere, and the somewhere is usually the contingency — which, in most programmes, was already insufficient for the known risks.
Business stakeholders frequently define "integration complete" as the day the merged entity begins to operate under a single brand and a single operating model. IT integration takes considerably longer than that. The gap between "Day One" — when the legal and commercial merger completes — and "IT Integration Complete" — when all systems are unified and both legacy estates are decommissioned — is typically measured in years, not months. Programmes that are not explicit about this distinction, and do not manage business expectations around it, spend significant energy defending a position (IT integration is complete) that is not true.
What the Plans That Work Look Like
The integration programmes that deliver closest to their original plans share several characteristics that distinguish them from the ones that do not.
They invest in discovery before committing to a plan. The programmes that plan most accurately are those that invest, before the integration plan is locked, in understanding the actual state of both technology estates. This discovery phase — typically six to eight weeks of intensive assessment — produces a plan that is based on what is actually there, rather than what the documentation says is there. It feels expensive before the programme has started; it is cheap relative to the cost of discovering the same things mid-programme.
They define the target state before choosing the integration approach. The question "which system wins?" — which organisation's platform will be the survivor — is often deferred because it is politically sensitive. Deferring it is expensive. Every month the target state is undefined is a month during which both estates are maintained, both teams are uncertain about their future, and the integration programme cannot make the decisions it needs to make. The organisations that integrate fastest make this decision early and stick to it.
They treat retention of key people as a programme workstream. The people who understand the target organisation's systems are the most critical resource in the integration programme. They are also the most at risk of leaving — because a merger creates uncertainty about their future, and because they are typically capable enough to have options. Managing that risk — through explicit retention commitments, clear role definitions in the combined organisation, and sustained leadership attention — is not an HR task that can be delegated. It is a programme risk that the programme director needs to own.
Questions for Programme Leaders
- Has the integration plan been built on a documented discovery of both technology estates, or on the information available during due diligence?
- Is the target state — which platform survives, which is decommissioned — defined and communicated, or still subject to organisational negotiation?
- Are the costs of parallel running budgeted against a realistic timeline, with explicit provision for extension?
- Is data migration a defined workstream with its own resources, timeline and quality gates — not a task scheduled for the end of the programme?
- Are the BaFin (or relevant regulator) obligations triggered by the merger fully scoped and resourced in the integration plan?
- Is there an explicit plan to retain the subject-matter experts whose knowledge of the target estate is critical to the programme?
Post-merger IT integration will always be complex, always be expensive, and will almost always take longer than the initial plan. The question is not whether to expect those outcomes but how much longer, and how much more expensive, compared to a well-planned programme versus a poorly-planned one. The difference, in my experience, is large enough to justify the investment in doing the planning properly.