Modernizing core systems: the case for the committee, not the technical guide

Imagine a committee that authorizes starting the replacement of the institution's central system over a weekend. There are more than four years of planning behind it, rehearsals, an internal pilot and vendor assurances. On paper, the preparation looks complete.

That is, in essence, what happened at a British bank: TSB's board and its sub-committee authorized, between 18 and 19 April 2018, the start of the migration, which was carried out over the weekend of 20 to 22 April. Serious problems appeared almost immediately, and the following Monday showed that preparation and sufficient assurance are not the same thing.

By "core" we mean here the system of record on which critical operations depend: customers, accounts, policies, orders, inventory, collections, reconciliations or reports, depending on the industry, and with it the other systems (channels, payments, accounting). This article is not a technical guide. It is the case for whoever has to decide: what a committee can learn from the public TSB case when the migration of critical data and functions is concentrated in a single event, what alternative exists, and how that alternative is presented to a committee that asks about risk, cost and dates. It is written for whoever answers for operations, budget or risk at a bank, a fintech, an insurer, a retail chain or a regulated company.

What TSB and the PRA published about the case

TSB, a British bank, carried out its main migration to a new platform in April 2018. The bank itself described the program as the most complex change it had ever undertaken and "one of the most complex in British banking history," with more than four years of planning [2]. According to the bank, the board authorized the main migration event on the basis of "a significant volume of objective evidence": management attestations, written and oral assurances from vendors, nine successful dress rehearsals and transition events, and a pilot with more than 1,600 employees [2]. Nor was the migration a single event from start to finish: according to TSB, it was done in stages (ATMs, card payments, mortgages and the mobile app, among others), and the all-at-once part was the main migration event for customer data [2].

That is, it was not improvisation. There was planning, rehearsals and assurance. Even so, according to the British prudential regulator (the PRA) [1] (TSB itself disagrees with some aspects of the independent review [2][5]):

• All TSB branches and a significant proportion of its 5.2 million customers were affected by the initial problems.
• TSB took until December 2018 to return to normal operation.
• The bank has paid 32.7 million pounds in redress [1] to customers who suffered harm.
• In December 2022, the PRA and the FCA (the UK's Financial Conduct Authority) jointly fined TSB 48.65 million pounds [4].
• In April 2023, the PRA fined the then chief information officer, 81,620 pounds [1] for failing to ensure that the bank properly oversaw the outsourcing of its 2018 migration program. Among other things, according to the regulator, he did not sufficiently reassess the third party's capabilities or obtain the necessary assurance on the readiness of the platform before giving assurances to the board.

There are two lessons for a committee, and neither is technical.

The first: declared preparation does not replace sufficient assurance. The board had a great deal of documentation. What the regulator questioned is how solid the assurance behind it was: according to the PRA, the person responsible did not take reasonable steps to ensure the bank obtained sufficient assurance from the third party about its readiness, nor did he give enough consideration to whether further investigation was needed before giving assurance to the board [1]. An "all green" in a presentation is not the same as that assurance.

The second: responsibility can reach individuals, not just companies. The fine on the chief information officer rests on the British regime of individual accountability for senior managers; in Mexico the applicable framework is different, and each institution must check it. The case shows that, under the applicable British regime, oversight of a third party can lead to individual accountability in addition to sanctions on the institution; it does not allow that consequence to be carried over automatically to the Mexican framework.

What this article does not do also matters. The committee of a Mexican institution might ask whether the same thing happens here, but this article does not compare Mexican sanctions or incidents. For a specific decision, the institution must identify the sector framework that applies to it and validate it with its legal, compliance and risk areas.

Why a single cutover concentrates the risk

Martin Fowler, author and reference in software architecture, puts it bluntly about replacing legacy systems: "we've seen this simple-sounding plan go down in flames most of the time" (our translation) [3]. The reason he gives is a business one, not a technical one: replacing a serious system takes a long time, and in the meantime users cannot wait for new features [3].

Translated into the committee's language, a single cutover brings together in one moment three things that are better kept apart:

1. The value tends to arrive at the end. For years money is invested and the business receives nothing it can measure. If the project slips, there is nothing partial to show.
2. The risk is concentrated on a single day. Customers, branches, digital channels, payments and reconciliations change at once. If something fails, everything can fail together.
3. Rollback is usually difficult or nonexistent. Once the data has migrated and Monday's operations have been written to the new system, going back to the previous one stops being a button and becomes another project.

Seeing those three points on one sheet helps the committee change the conversation. The question stops being "when do we finish?" and becomes "what happens if something goes wrong on cutover day and how much of the business is exposed?"

The alternative: in stages, with rollback

Fowler gave the alternative a name, taken from a plant that grows around a tree until it replaces it: the strangler fig. The idea is simple to explain to a committee: instead of switching off the old system and switching on the new one, you build around the old one, piece by piece, and move one function at a time. While a function is being moved, the previous system can keep serving the ones not yet moved, depending on the design of data, operations and controls. Fowler, citing Ian Cartwright, Rob Horn and James Lewis, mentions four activities (the order in which they are listed does not imply a sequence): understand the outcomes you want to achieve, decide how to break the problem into smaller parts, successfully deliver those parts and change the organization so that this can happen continuously [3].

And he is honest about the cost: building that transitional layer may look like a waste, but "the reduced risk and earlier value from the gradual approach outweigh its costs" [3]. That statement is his judgment, not a universal measurement; that is why your committee should test it with its own numbers, as explained below.

The practical difference from the single cutover can be seen in a comparison:

The last row matters. The staged path is not free, and whoever presents it as such loses credibility with a CFO.

Rollback does not happen on its own either. That a stage can be reversed is a property that is designed: which function is moved, how much traffic it receives, what signal indicates it is time to go back and who has the authority to decide. There are legitimate irreversible stages, but they keep a concentrated exposure within their scope and must be explicitly justified to the committee: what makes them irreversible, how the damage is limited and which controls compensate for the lack of rollback.

How it is presented to the committee

For this decision, the committee can prioritize three things, in this order, over technical detail.

1. The risk, with its rollback

The question worth answering on one page: what is the worst that can happen at each stage, and how do we go back? For each stage, three data points: which part of the business it touches, which indicator warns that something is going wrong and how long it takes to return to the previous state.

Scenario (illustrative, no client). An insurer with a medical expenses policy administered on a central system from two decades ago decides to start with quotes and not with issued policies. The first stage moves the quote calculation to a new component, while the central system keeps issuing. If the new quote gives results different from those of the current system by a percentage that the committee set beforehand, traffic returns to the previous calculation. What is exposed is one function, not the entire operation.

2. The cost of doing nothing

This is the part that is often omitted and that can weigh the most. A committee that sees only the cost of modernization compares a number against zero, and zero often wins. But keeping the current system also costs, and that calculation is best done with your own data, not with third-party figures. We do not use generic market percentages here on the share of budget going to legacy systems or on how many replacements fail, because they are not needed to decide this case. The committee's calculation should come from its own accounting, its incidents and its change lead times:

• how much is spent each year to maintain, patch and operate the current system;
• how long it takes today to launch a product, a rate or a regulatory change, and what revenue is deferred in the meantime;
• how many people concentrate the knowledge of the system and what happens if one leaves;
• which incidents or manual closes it attributes today to limitations of the core system.

If the committee does not have those figures, that is in itself the first finding and the first deliverable.

3. Measurable milestones, not percent complete

"We're at 60%" is a phrase that a replacement program can say until the day it fails. The milestones of a staged modernization can be measured in the business and not in the project:

• what share of traffic or operations already runs through the new component;
• how long it now takes for a rate, product or rule change to go out, compared with how long it took at the start;
• how many times rollback has been exercised and tested, and with what result;
• how much it costs to maintain the coexistence layer and on what date it is planned to be retired.

This last point avoids a known risk of staged approaches: that the transitional layer becomes permanent. Retiring it must be in the plan from day one, with a date and an owner.

The regulatory part is not left for the end

If one of the stages involves moving functions to the cloud or to a third party, your regulator's requirements are part of the schedule, not a later formality. In Mexico, the answer depends on the entity and the third party: credit institutions, electronic payment fund institutions (IFPE), insurers and bonding companies each have their own rules on contracting and overseeing third parties, which may provide for prior notice or authorization depending on the service and where it is provided. Before authorizing a stage, Legal and Compliance must confirm the applicable obligation, authority, filing and deadline. Three concrete questions to take to them: does this stage require prior notice or authorization from the CNBV (Mexico's banking and securities regulator) or the CNSF (its insurance regulator)? With how much lead time? What evidence of assurance over the third party does the regulator expect to see documented? The obligation, the competent authority and the deadline depend on the entity, the function, the data, the location of the service and the third party contracted. The TSB case illustrates that the British regulator did not only ask whether the system worked: it asked who gave assurance, to whom and with what evidence [1].

That is why it is advisable that each stage, when presented to the committee, come with a page like this attached: what is moved, who is notified, what test evidence exists and who is accountable.

Five questions for your next committee

1. How much of our business would be exposed on the worst day of the first stage, and how long would it take us to return to the previous state?
2. Have we quantified the annual cost of not modernizing, with data from our accounting and not from a vendor presentation?
3. What independent evidence of load and data testing do we have today, and who, other than whoever builds it, reviewed it?
4. What business milestone, not project milestone, are we going to see in the first six months? For example, a function running through the new component with real traffic.
5. Which body, function and responsible person does our applicable framework identify to oversee the third party, and what evidence must be kept?

If several answers are "I don't know," what is probably missing is not a vendor: it is information to decide.

Where to start this week

Before authorizing a larger program, you can start with a sheet with a single column of core system functions (customer onboarding, quoting, issuance, collection, reconciliation, regulatory reports) and, next to each, three marks: how much it changes per year, how many other systems depend on it and what would happen if it stopped for half a day. The committee can rate each function against five criteria: verifiable business value, dependencies on other systems, reversibility, representativeness of data and load, and regulatory condition. The first stage will be the one with the best balance for its context, not necessarily the easiest; a function that costs nothing if paused may yield a pilot of no relevance. With that criterion, the committee has an order to defend.

What Hábil does

Hábil supports organizations that need to decide how to modernize core systems without losing sight of continuity, control and traceability. That is the idea of the page Modernize the core without slowing the business; to join your systems and channels, the page Unify your operations and your channels.

The first assessment conversation is at no cost and serves to define the system, the pending decision and the information your committee would need to evaluate it. Write to us on WhatsApp.