The Data Side of a Merger

On 18 March 2026, UBS announced that every former Credit Suisse client, around 1.2 million worldwide, now runs on UBS infrastructure.^[4] The legal merger of the two parent banks had been done almost two years earlier. That gap between the legal deal and the data deal is what this article is about.

I know this story from the inside. I worked at UBS from 2017 to 2025, and in my last role, as Head of Information Security and Records Management for Group Finance, I defined the integration framework and led the Credit Suisse data integration workstreams within Group Finance. That is one function inside a very large programme, and I will not speak for the rest of it. Years before that, as a consultant, I had delivered regulatory reporting programmes for both banks. I will not write about anything internal here. Every fact about the integration comes from what UBS has published. The lessons are general ones, drawn from my whole career, and they are my own. But I can say one thing with confidence: when two banks become one, the hardest part is not the signature. It is the data.

A merger is signed in days. The legal entities can be combined in a year or two. The data takes longer, because data does not merge by decree. Two banks have two ways of naming a client, two ways of classifying a product, two sets of owners, two archives and two histories of decisions nobody wrote down. Every one of those has to be reconciled, migrated or retired, and each choice has a regulatory consequence.

UBS itself called this ^[4] "one of the most complex integrations in banking history". It is also the best Swiss case study a data leader could ask for, because the milestones are public, dated and measurable. Most Swiss companies will never merge two global banks. Many will buy a competitor, absorb a subsidiary or carve out a business. The same five data questions come up every time.

Part I · The Timeline

The Legal Deal Is Fast. The Data Deal Is Slow.

Look at the public milestones in order. The acquisition was announced on 19 March 2023 and completed on 12 June 2023, when Credit Suisse Group AG was merged into UBS Group AG.^[1] For a while, the group ran two separate parent banks, each with its own subsidiaries, branches and clients.^[1] The two parent banks merged on 31 May 2024, and the CEO described that step as critical to moving clients onto UBS platforms.^[2] The two Swiss banks followed on 1 July 2024.^[3] The last Swiss clients were migrated in March 2026, and UBS expects to substantially complete the integration by the end of 2026.^[4]

The pattern is clear. The legal work moves first, because it has to. The data work moves last, because it depends on everything else. You cannot migrate a client until you know which system will receive them, and you cannot switch off a system until you know what must be kept from it.

Recent coverage of the programme makes the same point from a testing angle. Each migration can touch client records, account structures, transaction history, permissions, reporting and regulatory data, and all of it must arrive complete and correct while downstream services keep recognising the client.^[6] That is not an IT problem with a data side. It is a data problem with an IT side.

A merger is signed by lawyers in a weekend. It is finished by data people years later, one client record and one archive at a time.

Bernard Millet, DataEdgePro.net

Part II · The Real Problem

Why Data Governance Arrives Late

In any integration, the first months are about continuity. The bank must stay open. Payments must flow. Regulatory reports must still go out on time, from two sets of systems, under one name. Nobody argues with that priority, and nobody should.

The problem is what continuity can hide. In any organisation that runs two estates side by side, teams build bridges: mappings between client identifiers, translation tables between product codes, manual reconciliations between reports. These bridges usually work. The risk is that they are built fast, by whoever is available, and not designed to last. If nobody documents them, the migration team may later find that important business rules live inside those bridges and nowhere else.

That is why, in many programmes across the industry, data governance risks arriving late and in a hurry. By then, the question is no longer how to design a clean data model. It is how to recover the meaning of data that two organisations understood differently for decades.

In the Swiss context, there is a second reason to start early. FINMA Circular 2023/1 on operational risks and resilience, in force since January 2024, significantly expanded the requirements for handling critical data, meaning data so important to the institution that it needs stronger protection.^[7] An integration does not suspend those duties. For a while, it doubles them, because the same critical data now lives in two places.

Part III · The Work

Five Data Workstreams Every Integration Needs

Strip away the size of the UBS case and five pieces of data work remain. They apply to a regional bank buying a private bank, to an insurer absorbing a portfolio, or to an industrial group integrating a competitor. What changes is the scale, not the list.

One. Inventory and lineage. You cannot migrate what you cannot see. Before any decision, both sides need a list of systems, data stores, reports and interfaces, and for the important ones, where the data comes from and where it goes. In a merger this is harder than usual, because each side describes its estate in its own language. The inventory is the first shared document of the new company, and it deserves an owner.

Two. Glossary and critical data elements. Two banks will both have a "client", a "household", an "account" and a "relationship manager", and the words will not mean exactly the same thing. Agree first on the critical data elements, the few dozen fields that drive regulatory reporting, risk and client service. Harmonise those definitions before migration, not after. The rest can follow.

Three. Ownership. During the transition, many data sets have two owners or none. The owner on the old side is leaving or busy. The owner on the new side has not yet taken the data on. Name one owner for each critical domain on the target platform, early, and give that person a say in how the data arrives.

Four. Regulatory continuity. Reports to FINMA, the Swiss National Bank and foreign supervisors do not pause for an integration. For some period, figures come from two estates and must still reconcile. This workstream protects the lineage of every regulatory number while its source systems change underneath it.

Five. Decommissioning and retention. The workstream everyone underestimates. Switching off a system is an IT task. Deciding what happens to the records inside it is a legal and data task, and it comes with Swiss obligations I cover in Part V.

Read the last row carefully. Decommissioning peaks at the end, but its open circles start before closing. That is deliberate. The retention rules you will need at the end should be agreed at the start, while the people who know the old systems are still there.

Part IV · The Choice

Absorb, Merge, or Pick the Best of Both

Every data domain in an integration faces the same question: which version survives? There are three honest answers, and each has a cost the data team pays.

UBS chose a clear path in public: former Credit Suisse clients were moved onto UBS infrastructure, and the legacy systems are being retired.^[4] In general, from a data governance point of view, a single clear direction is a gift. It tells every data owner which definitions win, which model is the target and which archive will be closed. The debates become practical rather than political.

In my view, the "best of both" option is the one that looks wise on a slide and hurts most in practice. It is sometimes right. But each exception creates a new interface, a new mapping and a new owner to agree with. If you choose it, choose it for a few domains with a clear reason, and write that reason down.

Part V · The Last Mile

Switched Off Is Not the Same as Gone

The UBS second quarter report for 2026 gives two numbers side by side. More than 90% of legacy Credit Suisse applications in scope were no longer in use. Around 70% had been fully decommissioned.^[5] Both numbers are good progress. What interests me as a data person is the space between them.

A gap like this is normal in any large programme, and UBS says it expects decommissioning to be substantially complete by year end.^[5] I do not read it as a problem. I read it as the place where data governance does its most careful work, because an application that nobody uses can still hold records the bank must keep.

Swiss law is precise here, and it pulls in two directions. On one side, article 958f of the Code of Obligations requires accounting books, records and annual and audit reports to be kept for ten years from the end of the financial year, on paper or electronically, as long as they stay accessible.^[8] Sector rules, including banking and anti money laundering law, can add their own retention duties.^[9] On the other side, the Federal Act on Data Protection sets no fixed retention period, and the principle of proportionality means data that is no longer needed should be destroyed.^[9] Legal commentary adds that a real retention duty or a legitimate interest, such as possible legal disputes, can justify keeping data longer.^[10]

So before a legacy system can be retired, someone must answer, record by record type: keep or delete, for how long, on what legal basis, in which archive, readable by whom. That someone is rarely the IT team alone. It is data owners, legal, compliance and the data office, working from one retention schedule.

Records management was part of my role in my last years at UBS, which is why this topic matters so much to me. The two risks above are general ones that any organisation faces when it retires systems. Both are quiet at first. Neither shows up on the day the system is switched off. They show up years later, in an audit, a lawsuit or a data subject request. That is why I would put the retention schedule in the programme plan from the first month, not in the final wave.

Turning off a system takes an afternoon. Deciding what it leaves behind should take months, and it should start on the first day.

Bernard Millet, DataEdgePro.net

Part VI · The Scorecard

What to Measure

Integration programmes are full of dashboards about clients migrated, servers retired and savings achieved. Those matter. But none of them tells you whether the data arrived with its meaning intact. A few simple measures do. Pick four or five, give each an owner, and review them at every steering committee.

One warning. The retention measure can look perfect on paper if every decision says "keep everything". Pair it with a simple review: for a sample of decisions, check that a legal basis and a period are written down. A decision without a reason is not a decision.

Part VII · What to Do Next

If an Integration Is Coming Your Way

Most readers of this publication will not face a merger of two global banks. Many will face a smaller version of the same thing: an acquisition, a carve out, or two business units forced onto one platform. The steps below work at any size.

Conclusion: The Data Deal Decides the Outcome

The UBS and Credit Suisse integration will be studied for years, for its speed, its scale and its cost savings. For data leaders, the most useful lesson is quieter. The legal steps were done in about sixteen months. Moving 1.2 million clients, testing each wave and retiring the old estate is taking far longer, and it is where the real risk sits.^[4][5]

That is true in any merger, large or small. The deal team closes the transaction. The data team decides whether the new company can trust its own numbers, answer its regulators and honour its retention duties once the old systems are gone. Treat data governance as a workstream from the first week, not as a clean up at the end, and the last mile becomes a plan instead of a surprise.

If I had to leave one sentence with a CDO about to enter an integration, it would be this: agree who owns the data, what it means and what you will keep, before you move a single record.