Context
A state development bank, an IT organisation of more than 300 people, and an application portfolio that had grown for two decades around a single core system. We ran the enterprise architecture practice there and chaired the Architecture Review Board, through which every material technology decision passed. During that period the bank committed to replacing its core banking platform: the largest technology transformation in its history.
Problem
A core banking system is not an application you swap out. It is where years of knowledge about products, exceptions and processes have settled, including the knowledge that was never written down anywhere except in the code and the data. Dozens of integrations, regulatory reporting and business processes depend on it, and their business owners tend to discover that dependency only when the core stops responding.
The instinctive response, treat it as one large implementation project, one vendor, one plan, fails on arithmetic rather than technology. More than ten project teams worked in parallel, across different vendors and different cadences. Each of them had to make decisions faster than any central plan could approve them. Without shared constraints those decisions diverge quietly and meet for the first time during integration testing, which is the most expensive place available.
The second problem only became measurable late: data migration. It occupies one line in a plan, and in practice it is where every mismatch between the old and the new model surfaces, records with no counterpart, history in formats the new model does not anticipate, data that is technically valid and substantively useless.
Approach
Architecture's job was not to design on behalf of the teams. It was to hold one shared map of dependencies and a narrow set of decisions that were not open to local negotiation: integration contracts, the reference data model, and the boundary of responsibility between the core and its satellites. Everything outside that set stayed with the teams.
An Architecture Review Board becomes a bottleneck very easily, every project waits for Thursday. We handled that with three rules. Reversible decisions do not need the board; they need a record. The board takes what is expensive to reverse or what crosses a team boundary. An incomplete submission is not rejected in session but returned earlier, with a statement of what is missing. A board that mostly says no stops receiving submissions within a quarter, projects stop asking, and the architectural decisions happen anyway, outside the register.
We treated data migration as a work stream with its own cadence rather than a final implementation phase: trial runs at production volumes from an early stage, reconciliation figures signed off by the business rather than by IT, and an explicit decision about what would not be migrated into the new core but left in a read-only archive. That last decision was the hardest politically and the most profitable technically.
Outcome
The bank went through a core system replacement with architectural coordination maintained across more than ten teams and multiple vendors, in an IT organisation of over 300 people. More durable than the implementation itself was that the architecture decision register and the integration contracts outlived the programme and became the entry point for subsequent change.
What it taught us
Replacing a core is an organisational problem with a technical symptom. It is settled not by the choice of vendor but by whether the organisation can keep decisions coherent when a dozen groups are making them at the same time.
Architecture governance works only while it is faster than the route around it. A board with a two-week queue is not a control; it is an incentive to decide without it. And if a transformation plan gives data migration less attention than platform selection, it is not a plan, it is a spending sequence.