There is a well-documented paradox at the heart of mergers and acquisitions in financial services. The rationale for a transaction — cost synergies, market consolidation, capability acquisition, regulatory simplification — is developed and agreed at the strategic level, with financial modelling that assigns precise values to anticipated cost reductions and revenue benefits. The IT integration programme that is required to realise those synergies is treated, in most transactions, as an implementation detail to be managed below the level at which the deal is evaluated. It is not. IT integration is where M&A value is either captured or destroyed, and it routinely destroys more value than it captures in institutions that do not understand this until the integration is already in difficulty.
This article draws on direct experience leading banking M&A IT integration programmes — most substantively, the three-year programme to merge Von Essen Bank and Consors Finance into a single BNP Paribas German Branch, and the integration of Clerical Medical's mainland Europe business into Heidelberger Leben within a Lloyds Banking Group restructuring — as well as portfolio-level M&A integration work at ResMed across 27 European entities. The patterns are consistent across transactions of very different scale and sector.
The Four Phases Where Integration Fails
M&A IT integration has a predictable lifecycle. The failure modes are different in each phase, but the most expensive ones are those that occur earliest — because the cost of early errors compounds throughout the subsequent phases.
IT Due Diligence: What It Must Cover and What It Typically Misses
IT due diligence in most M&A transactions is conducted under time pressure, with limited access to the target's technical teams, and against a scope that is negotiated with the target rather than determined by what an acquirer actually needs to know. The result is due diligence reports that cover the visible and documented aspects of the IT estate — licensed software, major systems, reported incidents, headline cost figures — while systematically missing the issues that will dominate the integration programme.
The most consistently missed issues are: undocumented interfaces between systems, whose number is almost always larger than the target's own estimate; data quality problems in core systems that are invisible until a migration attempt makes them visible; technical debt in core banking systems that has been managed operationally rather than addressed architecturally; regulatory compliance gaps that the target has either not identified or not disclosed; and key person dependencies — the senior technical staff whose departure risk increases materially the moment a transaction is announced.
Effective IT due diligence requires access to people, not just documents. The most valuable information about a banking IT estate sits with the architects, technical leads and operations managers who have been working in it for years — not in system inventories and licence lists. A due diligence process that does not include structured technical interviews with these individuals will consistently miss the issues that matter most.
"The surprises that derail banking M&A integrations were almost always knowable at due diligence. They were not found because the due diligence was designed to confirm the deal rather than to challenge it."
Day 1: The Deadline That Cannot Move
Legal Day 1 — the moment the transaction closes and the entities are legally combined — is a hard deadline that is determined by regulatory approval, not by integration readiness. BaFin must approve significant banking transactions; the ECB notification requirements for significant supervised entities add a further regulatory timeline that operates independently of the integration programme. These timelines are fixed. The integration programme must plan backward from them.
The Day 1 requirements for a banking merger are specific and non-negotiable. On Day 1, the merged entity must be able to operate as a single legal entity for regulatory purposes — which means unified reporting to BaFin, a single set of consolidated accounts, and the ability to transact with counterparties, regulators and customers as the merged entity. It does not require that all systems are consolidated — that is the work of the integration programme that follows. What it requires is that the operational layer is functional: customers can access their accounts, payments can be processed, risk positions can be reported, and the regulatory obligations of the merged entity can be met.
The failure mode at Day 1 is invariably a consequence of underestimating the complexity of what "functional" means. In the BNP Paribas merger programme — integrating Von Essen Bank and Consors Finance into a single German branch — the Day 1 scope required not only that the combined entity could operate but that the outsourcing of two distinct product lines (Deposit and Secured) had been structured and contracted, the vendors for those product lines had been selected through competitive RFP processes, and the contractual framework for the new operating model had been established. Each of these had its own critical path running to the same Day 1 deadline.
The Three Integration Archetypes — and Why Getting the Choice Right Matters
Before the integration programme can be planned, a fundamental strategic decision must be made: what is the target state? In banking M&A, there are three archetypal answers, and the choice between them determines the integration programme's scope, timeline, cost and risk profile.
The choice of archetype is strategically significant because it determines whose IT organisation, whose processes, and whose ways of working become the target state. In practice, these choices are frequently not made clearly at the outset — they are left ambiguous, and the integration programme makes de facto archetype choices through individual system decisions that accumulate without a governing strategic framework. The consequence is integrations that take longer, cost more, and produce less coherent target states than would have resulted from a clear archetype decision at the beginning.
Why the Technology Is Never the Hard Part
The technical challenges of M&A IT integration are real, substantial and well-documented. System consolidation, data migration, interface rationalisation, and application decommissioning are demanding programmes of work that require significant technical expertise and programme management discipline. They are also, fundamentally, predictable. The problems that arise in technical integration — data quality issues, interface complexity, performance under combined load — are ones that experienced teams have encountered before and know how to address.
The challenges that consistently derail banking M&A IT integrations are not technical. They are organisational, cultural and political — and they are the ones that the IT function is least equipped to resolve independently.
The Data Migration Reality
If there is a single technical element of M&A IT integration that is most consistently underestimated, it is data migration. The assumption underlying most integration plans is that data can be extracted from legacy systems, transformed to the target format, and loaded into the new environment with known, manageable complexity. In practice, banking data migration is almost always more complex and more time-consuming than this assumption implies.
The reasons are predictable once encountered, though consistently underestimated in advance. Banking data has typically been accumulated over decades in systems with evolving data models, inconsistent data quality standards, and undocumented business rules embedded in the data itself rather than in the application layer. Customer records that look complete in the source system turn out to have missing or inconsistent mandatory fields when viewed against the target system's validation rules. Accounts that have been migrated multiple times through previous system changes carry artefacts of those migrations that do not translate cleanly. Products that existed in the source entity but have no equivalent in the target entity require data transformation rules that can only be defined through detailed business analysis, not through technical mapping alone.
The practical implication is that data migration must begin much earlier in the integration programme than most plans assume — not because the actual migration takes longer, but because the discovery of data quality issues, the definition of transformation rules for complex data scenarios, and the remediation of data problems in the source system are each programmes of work in their own right. In the BNP Paribas merger, customer data from two separately operated banking entities — each with their own account structures, product definitions, and customer relationship models — required systematic data quality assessment, business rule definition, and iterative migration testing before a production-quality migration plan could be established.
The Run/Change Tension: Operating and Integrating Simultaneously
One of the most structurally difficult aspects of banking M&A integration is that the integration programme must be executed while both entities continue to operate as banks. Customers continue to transact. Risk positions continue to evolve. Regulatory reports continue to be due. New products continue to be launched. The integration programme must find a way to make substantial changes to core banking systems and processes without disrupting the ongoing operation of the bank — and must do so with teams whose attention is divided between keeping the existing bank running and building the merged entity.
This tension — known in programme management as the Run/Change divide — is acute in banking M&A because both dimensions are non-negotiable. The bank must continue to run. The integration must continue to progress. The demand for experienced IT staff from both dimensions simultaneously creates a resource constraint that most initial integration business cases underestimate.
The practical management of this tension requires explicit decisions about resource allocation — which teams and individuals are ring-fenced for integration work and which remain dedicated to run operations — and governance arrangements that prevent run priorities from consistently crowding out change priorities. Without these, the natural tendency of operational urgency to dominate strategic importance produces integration programmes that are perpetually delayed by operational demands that were entirely foreseeable.
In the BNP Paribas merger programme, a significant element of the integration involved not just merging two IT estates but simultaneously outsourcing two distinct product lines — Deposit and Secured — to third-party providers. This added a dimension to the integration that is worth noting explicitly: an outsourcing decision made as part of an M&A integration programme is not just a vendor selection exercise — it is an architectural decision that shapes the target state IT landscape and the ongoing operating model simultaneously. The RFP process for each outsourced product line had to be designed and executed with full knowledge of the integration context, the Day 1 timeline, the regulatory requirements of the merged entity, and the operational constraints of transitioning live banking products to new providers. Each of these dimensions added requirements that a standalone outsourcing RFP would not have needed to address. Institutions that treat M&A-linked outsourcing decisions as separable from the integration programme — managing them on parallel tracks without explicit dependency management — consistently create handover problems at the boundaries between the two workstreams.
The Regulatory Dimension in German Banking M&A
Banking mergers in Germany operate within a regulatory framework that is more demanding than many other European jurisdictions and that must be treated as a hard constraint by the integration programme, not as a compliance layer to be addressed at the end.
BaFin's approval process for significant banking transactions involves assessment of the combined entity's governance, risk management framework, IT systems and operational resilience. The documentation required for regulatory approval overlaps substantially with the integration planning work — the IT architecture for the merged entity, the risk management framework, the capital adequacy assessment — and this overlap should be exploited rather than managed as a parallel exercise. Integration planning work that produces outputs suitable for regulatory submission reduces both the integration programme's burden and the time from submission to approval.
From DORA's perspective, a merger creates specific ICT risk management obligations. The combined entity's ICT risk management framework must cover the merged IT estate from Day 1. Third-party risk assessments must be updated to reflect any changes in the combined entity's ICT provider relationships. Business continuity and incident response plans must address the combined entity's scope. These are not obligations that can be addressed after the integration is complete — they apply to the merged entity from the moment the transaction closes.
Questions for Integration Sponsors and Programme Leaders
- Has the IT due diligence included structured technical interviews with the target entity's key architects and technical leads — not just review of documentation and system inventories?
- Has the integration archetype (absorption, merger of equals, best-of-breed) been decided clearly at the strategic level, with governance in place to prevent individual system decisions from contradicting it?
- Is the Day 1 scope defined with sufficient precision that every workstream knows exactly what it must deliver by close — and has that scope been validated against the regulatory approval requirements?
- Has a key person retention plan been established for the technical staff on both sides whose departure would materially damage the integration programme?
- Has data migration been scoped to include data quality assessment and business rule definition, not just technical migration — with an adequate timeline for the discovery work that precedes the migration itself?
- Are resource allocation decisions between run and change explicit and enforced — with governance arrangements that prevent operational urgency from permanently crowding out integration progress?
- If outsourcing decisions are being made as part of the integration, are the integration dependencies of those decisions explicitly included in the RFP requirements and vendor evaluation criteria?
- Has the integration planning work been designed to produce outputs that can be used directly in BaFin regulatory submissions, minimising duplication of effort between integration and regulatory workstreams?
Conclusion: M&A Value Is Captured in the Integration, Not the Deal
The strategic logic of a banking merger or acquisition is validated or invalidated by the IT integration programme that follows it. Cost synergies that require system consolidation are only realised when the systems are consolidated. Revenue synergies that require a common customer platform are only realised when the platform exists. Regulatory simplifications that require unified risk reporting are only achieved when the data flows support them. None of these outcomes emerges from the deal itself — they are all dependent on an integration programme that delivers the target state reliably, within the time and cost parameters that the business case assumed.
The institutions that consistently achieve their M&A integration objectives share a small number of characteristics: they invest appropriately in IT due diligence before close; they make the archetype decision clearly and govern it consistently; they plan Day 1 as the hard deadline it is; they address the organisational and cultural dimensions with the same rigour they apply to the technical ones; and they manage the Run/Change tension explicitly rather than allowing it to resolve itself through default prioritisation.
Most importantly, they understand that the challenge of M&A IT integration is not primarily technical. The technology is manageable. The organisations, the cultures, the politics, and the people — those are where the real complexity lives, and where the real leadership is required.