Core Banking Modernization: Strangler Fig, Event-Driven Cores and Migration Risk (2026)

Disclaimer: this article is architecture analysis for engineers and is not financial, legal, regulatory or investment advice.

Most banks do not run a core banking system so much as inherit one. A mainframe application written in COBOL decades ago still posts the balances, accrues the interest and runs the nightly batch, surrounded by thirty years of adapters, extracts and spreadsheets that nobody dares remove. It works, which is exactly the problem: the cost of change rises every year while the business asks for real-time payments, instant product launches and open APIs that the batch-oriented design was never built to give.

The industry’s answer in 2026 is not one big replacement but a managed, progressive migration. Core banking modernization today means putting a routing facade in front of the legacy core, moving products and customer cohorts to a new ledger-centred core one slice at a time, and running both worlds side by side under strict reconciliation until the old one can be switched off. This guide explains the mechanics, the numbers behind cutover planning, and the failure modes that sink programmes.

What this covers: why legacy cores resist change, big-bang versus progressive migration, the strangler fig pattern and anti-corruption layers, event-driven and composable core designs, where the ledger of record lives, parallel run and reconciliation, data migration, cutover rehearsal arithmetic, ISO 20022 coexistence, operational resilience regulation including DORA, vendor categories, and a practical checklist.

Context and Background

A core banking system is the system of record for accounts, balances, products and postings. Traditional cores bundle everything: customer master data, product definitions, interest and fee calculation, the general ledger interface, end-of-day batch processing and often channel logic. They typically run on mainframes or large Unix systems, are written in COBOL or comparable languages, and process work in a daily cycle in which online transactions are captured during the day and settled in an overnight batch window. That batch window is both the architecture and the constraint: if the batch overruns, the bank cannot open.

Three pressures make this model hard to sustain. The first is real-time expectation. Instant payment schemes and always-on mobile channels mean a balance must be correct at 03:00 on a Sunday, not just after the batch. The second is product agility: launching a new savings tier in a monolithic core can mean a change request queue measured in quarters because every parameter touches shared code. The third is talent and risk: the pool of engineers who understand the core shrinks, and each change carries regression risk across a tightly coupled codebase.

None of this means legacy cores are bad software. They are extraordinarily reliable, battle-tested on correctness, and their economic cost is partly a sunk cost. The honest framing is that they are optimised for a different set of constraints, and the migration problem is about moving risk-weighted functionality without interrupting a regulated, always-trusted service.

The market has responded with vendor categories rather than a single standard. Established suite vendors such as Temenos and Infosys Finacle offer modernised, componentised core platforms. Cloud-native and “composable” entrants such as Thought Machine (with its Vault Core) and Mambu present configurable, API-first engines, often with product behaviour expressed as code or configuration rather than hard-wired parameters. Each of these claims differing degrees of cloud-native design, hosting flexibility and product modelling freedom; treat vendor claims as claims, and evaluate them against your own load, regulatory and integration profile rather than against a slide. This article stays vendor-neutral on purpose.

Two adjacent topics shape the design and are covered in depth elsewhere on this site. The way a modern ledger records state as an immutable event history is explored in our guide to event sourcing, bitemporal data and CQRS for financial ledgers, and the message formats that move value between the core and the outside world are compared in ISO 8583 versus ISO 20022 card and payment messaging. The migration discipline below sits on top of both.

A final piece of vocabulary. A system of record is the one component whose answer to “what is the balance?” is authoritative. A ledger of record is the narrower claim: the double-entry journal from which balances are derived. During migration, the hardest question is never “which technology” but “which system is the record, for which accounts, at which moment” because the answer changes and must be unambiguous at every instant.

The Strangler Fig Reference Architecture for Core Banking Modernization

The strangler fig pattern, named by Martin Fowler after a vine that grows around a host tree and eventually replaces it, is the dominant approach to legacy core migration. Instead of replacing the core in one event, you place a routing facade in front of it, build new capability behind that facade, redirect traffic slice by slice, and retire the legacy pieces as they empty out. At every moment the bank runs a working system.

Direct answer: a strangler fig migration puts a routing layer between channels and the core, then moves products, customer cohorts or functions to a new core incrementally while an anti-corruption layer translates between the two data models. Legacy shrinks until it can be decommissioned, so risk is spread across many small, reversible cutovers instead of one irreversible one.

Figure 1: Reference architecture for a strangler fig core banking migration, showing the routing facade, both cores, the anti-corruption layer and the event backbone feeding payments, data and reconciliation.

The diagram shows the moving parts. Channels never talk to a core directly; they talk to a routing facade that decides, per request, whether the account in question lives on the new or the old core. The new core publishes its postings through a transactional outbox to an event backbone. The legacy core, which cannot publish events natively, is observed through an anti-corruption layer that converts its extracts, journals or change records into the same canonical events. Downstream consumers (data platform, payments hub, reconciliation service) see one coherent stream regardless of where a posting originated.

The routing facade decides who owns an account

The facade is the strangler’s trunk. Its routing table maps each account, customer or product identifier to the core that currently owns it, and that table is itself critical data. A request for an account that has been migrated goes to the new core; a request for an unmigrated account goes to the legacy core; a request in flight during a cutover is held or rejected according to explicit rules.

Three design choices matter. First, routing granularity: by product (all current accounts of type X), by customer cohort (accounts opened in a given period or branch) or by customer (every product for a customer moves together). Customer-level routing avoids cross-core joins, such as a mortgage on the new core secured against a deposit on the old one, but makes cohorts large. Second, atomicity of the routing flip: the change of owner for an account must be a single, auditable, reversible state change, ideally with a short freeze window. Third, the facade must be at least as available as the cores it fronts; otherwise you have built a new single point of failure in front of two reliable ones.

The anti-corruption layer protects the new model

An anti-corruption layer, a term from domain-driven design, is a translation boundary that stops the legacy data model leaking into the new one. Legacy cores tend to encode business meaning in positional fields, status codes with undocumented combinations, and product flags whose semantics changed over decades. If the new core adopts those shapes it inherits the debt it was bought to escape.

In practice the layer maps legacy records to a canonical model: account, party, product, posting, balance and limit. It handles code translation (a legacy status “07” becomes an explicit state in a state machine), unit and rounding conventions, and calendar differences such as how value dates and business days are derived. It is also where you capture hard-won knowledge: every odd mapping becomes a tested, versioned rule rather than tribal memory. Treat the mapping table as production code with unit tests built from real, anonymised cases.

The event backbone makes both cores observable

Event-driven banking is useful in a migration for a reason that has little to do with fashion. A shared event stream gives you a neutral record of “what each core believed happened,” which is exactly what reconciliation needs. It also lets new consumers (fraud scoring, customer notifications, risk aggregation) subscribe once and keep working while the producer behind the facade changes.

The reliability of the stream depends on how events are produced. A core that updates its database and then publishes to a broker in two separate steps will eventually lose or duplicate an event. The standard remedy is the transactional outbox, where the event is written in the same database transaction as the state change and relayed afterwards; we cover the mechanics and the change-data-capture variants in our guide to the transactional outbox pattern with CDC and exactly-once publishing. On the legacy side, where you cannot add an outbox, you typically mine change data capture from the database logs or from the end-of-day journal, accepting a coarser latency.

What “event-driven core” does and does not mean

The phrase is overloaded, so it helps to separate three ideas. An event-driven integration layer means the core emits events for others to consume; most programmes adopt this first and it carries modest risk. An event-sourced ledger means the core’s own state is the replayable log of immutable postings, with balances derived as projections; this gives an excellent audit trail and the ability to answer “what did we believe on date X” but changes how you reason about corrections. A fully asynchronous core means even postings are processed through queues with eventual consistency; this is rarely appropriate for the posting path itself, where a customer expects the balance to reflect a payment immediately.

The pragmatic position, shared by most architects who have shipped one of these, is to keep the posting path strongly consistent within the core and make everything around it event-driven. The ledger should commit atomically; the world should learn about it through events.

Composable Core Banking and Where the Ledger of Record Lives

Composable core banking splits the monolith into independently deployable capabilities (product catalogue, accounts and ledger, payments, limits, pricing, customer data) connected by APIs and events. The aim is to replace or evolve one capability without touching the rest. The design question that decides success is where the ledger of record lives, and whether you split it at all.

There are three common placements, each with a different risk profile:

Pattern	Ledger of record	Strength	Main risk
Hollow-out	Legacy core keeps the ledger; new services take channels, products, pricing	Lowest cutover risk; fast customer-facing change	Legacy stays on the critical path; cost of ownership persists
Ledger-first	New ledger takes balances and postings; legacy retained for unmigrated products	Real decommissioning path; clean audit story	Hardest migration; every posting path must be rebuilt
Parallel core	New core runs the new products from day one; old products remain until natural run-off	Isolates new business from legacy; simple scope	Two operating models for years; unclear end date

Hollow-out is attractive because it delivers visible benefits early, but it can become a permanent state in which the legacy core is merely hidden. Ledger-first has the strongest decommissioning story because balances are the thing that anchors every other dependency. The parallel-core approach is common for banks launching a digital brand or a new product line, and it works well when the old book is in run-off, but the old book often refuses to run off.

Why the ledger is the hinge

Everything else in a bank can be reconstructed from the ledger: statements, regulatory reports, accruals, customer-facing balances. If the ledger is wrong, no downstream fix is trustworthy; if it is right, other components can be rebuilt. That is why mature programmes decide the ledger placement first and refuse to blur it. At no point should two systems both believe they may originate a posting on the same account.

A modern ledger is typically double-entry, append-only and idempotent: every posting has a unique reference, replays of the same instruction are detected and ignored, and corrections are new postings rather than edits. Bitemporal modelling, which separates valid time (when something was economically true) from transaction time (when the system learned it), makes backdated corrections explainable instead of mysterious. These properties matter in a migration because reconciliation relies on stable business keys and on being able to say “this posting existed in system A at time T.”

Product engine versus ledger

Another split worth making explicit is between the product engine (which decides what a posting should be: interest accrual, a fee, a repayment schedule) and the ledger (which records it). Legacy cores fuse them. Several newer platforms keep them in one product but expose product behaviour as configuration or code that is versioned and testable. If you split them across components, you must define the contract carefully: the product engine emits posting instructions, the ledger validates and commits them, and the instruction carries enough context (value date, correlation id, source product version) to support later reproduction. Lose that context and you cannot explain a balance a year later.

Data ownership and the customer master

Customer data usually gets less attention than accounts, and then causes the late-stage surprises. Legacy cores often own customer master records (names, addresses, identifiers, relationships), and downstream systems depend on those identifiers. Decide early whether the new architecture introduces a separate customer or party service, and how legacy identifiers map to it. A stable cross-reference table that survives the whole migration is worth more than any clever tooling, because every reconciliation, regulatory report and customer-service lookup eventually needs to answer “which record is this, on which core.”

Migration Strategy: Big-Bang, Progressive, and the Parallel Run

The conventional wisdom, repeated in programme post-mortems, is that big-bang migrations of core banking are risky and progressive ones are safer. The reasons are mechanical rather than cultural. A big-bang cutover concentrates every unknown into a single weekend: data quality defects, performance behaviour at real volume, integration quirks, operational readiness and customer communication all meet at once. If something fails, the rollback path is often unrealistic, because after the cutover customers have transacted on the new system and the old one is stale.

The best-known cautionary example in the United Kingdom is the TSB migration of April 2018, in which the bank moved its customer data to a new platform and large numbers of customers lost access to or saw incorrect information in their accounts for an extended period. The independent review commissioned by the bank’s board, conducted by Slaughter and May and published in late 2019, and the later enforcement action by the UK regulators, are public and worth reading. The lessons that engineers usually draw are about testing realism, readiness governance and the gap between a technically successful data move and an operationally successful service; this article avoids restating specific figures from memory, so check the published reports for exact numbers and findings.

Progressive migration reduces the blast radius per step, but it is not free. It needs the facade, the anti-corruption layer and reconciliation, all of which are extra systems to build and run for years. It also stretches the programme, with attendant risk of attention fatigue and budget scrutiny. The decision is therefore not “progressive good, big-bang bad” but “what is the cost of a failed cutover relative to the cost of running two worlds.”

Figure 2: The migration loop for a legacy core migration. Each cohort passes through shadow run, parallel run and a rehearsed cutover, with a tolerance gate that either advances the next cohort or rolls back.

The loop in Figure 2 is the engine of the programme. You do not run it once; you run it for every cohort, and each pass should be faster and less eventful than the one before. The gate at the end is the most important design element: a pre-agreed, numeric definition of “within tolerance” and a rehearsed rollback.

Sequencing: what moves first

Sequencing is a risk-ranking exercise. Teams commonly start with new products or new customers, because there is no historical data to migrate and the old core is untouched. Next come simple, high-volume, low-complexity products such as basic current accounts or savings with few features, and last the complex ones: loans with long schedules, products with embedded options, joint and corporate structures, and anything tied to regulatory reporting quirks.

A useful heuristic is to sort candidate cohorts on two axes: customer impact if wrong and semantic complexity of the product. Migrate low-low first to learn the machinery, and defer high-high until the machinery is boring. Employee accounts are a popular early cohort for the same reason: staff are motivated, tolerant and well placed to give accurate feedback, though they are not representative of the full variety of customer behaviour.

Shadow run and parallel run are different things

A shadow run feeds the new core the same inputs as the old one but does not use its outputs. Nothing the new core does affects customers; you compare what it produced against what the legacy produced. A parallel run goes further: both systems process live activity and are formally reconciled, and the bank operates with the ability to switch which one is authoritative. Shadow is cheaper and safe. Parallel exercises operational procedures but needs strict discipline about which system answers the customer.

Both depend on replayable input. If you can record the stream of instructions that hit the legacy core (payments, adjustments, interest runs, fees) in a form that can be replayed against the new one, you can run months of history through the new core before touching a single live account. That is a stronger test than any synthetic suite, because real data contains the pathological cases that no one thought to write down.

Parallel Run and Reconciliation in Practice

Reconciliation is where a programme proves itself. During parallel run the two cores each produce a stream of postings and end-of-day balances for the same business events, and a reconciliation service decides whether they agree. The design below keeps the old core as the authoritative responder while the new core shadows it, then inverts the roles at cutover.

Figure 3: Dual posting during parallel run. The old core remains the system of record and answers the channel; the new core posts the same instruction, and a reconciler matches both event streams by business key and reports breaks.

The matching problem

Matching two ledgers sounds like a join and behaves like a research problem. Postings on the legacy core and the new core rarely share a native key, so the facade must stamp every instruction with a correlation identifier that both cores carry through. Where that is not possible (batch-originated postings such as interest), you match on a composite of account, value date, amount, currency and posting type, and accept a controlled false-match rate that you then measure.

Breaks (unmatched or mismatched items) fall into recognisable families. Timing breaks arise because one core posts on a different business day than the other. Rounding breaks come from differing rounding rules, order of operations in interest calculations, or day-count conventions. Semantic breaks reflect genuinely different treatment of a product rule, and these are the ones that reveal real defects or undocumented legacy behaviour. Data breaks stem from migrated balances or attributes that were wrong at load.

Tolerances and thresholds

A tolerance must be defined per break family, in advance, and ideally in business terms. A reasonable structure is: zero tolerance for balance differences on customer-visible fields beyond a stated rounding unit; a defined, small rate of unexplained breaks per million postings with a requirement that every break is classified within an agreed number of working days; and an unconditional gate for any break that touches regulated reporting figures. The specific numbers are bank-specific, so treat any figure in a template as a starting point for negotiation with risk and finance, not a standard.

The reason to formalise tolerances is political as much as technical. Under the pressure of a date, the temptation is to relabel a defect as “within tolerance.” A pre-agreed, signed definition makes that harder, and gives the programme a defensible audit trail when the regulator asks how the decision to cut over was made.

Illustrative reconciliation arithmetic

Consider a cohort of 200,000 accounts that together generate, on average, 12 postings per account per month. That is 2.4 million postings a month, roughly 80,000 per day. Suppose parallel run is planned for three full month-end cycles to exercise interest, fees and statements. If an unexplained-break target of one per million postings is set, the target allows about 2.4 unexplained breaks per month; in practice you will start far above that, perhaps hundreds per day in the first week while mappings are fixed. These figures are illustrative, not benchmarks, but the point generalises: reconciliation volume is high enough that unclassified breaks pile up unless the classification itself is automated.

That argues for building the reconciler as a product, not a script. It needs a rules engine to auto-explain known break types, a case-management workflow for the rest, a record of every decision, and dashboards that show break rate by family over time. The trend, not the instantaneous count, tells you when the cohort is ready.

Idempotency and replay

Because the same instruction is posted to both cores, the new core must handle repeats safely. Every instruction needs a unique, stable identifier, and the ledger must treat a second submission as a no-op that returns the first result. This is the same property that makes payment APIs safe to retry. It also allows you to replay a day against the new core after fixing a defect and obtain a clean result. Without idempotency, replay-based testing becomes dangerous, which is a strong reason to design it in from the start.

Data Migration and Cutover Rehearsal Math

Data migration is the part of a legacy core migration that looks like plumbing and behaves like archaeology. Decades of accounts carry history that predates current validation rules: fields with impossible values, balances that only reconcile because of a manual adjustment from 2009, products whose terms live in a scanned contract. The new core’s stricter model will reject or mangle this data unless you plan for it.

Profile first, migrate second

Begin with data profiling on the real legacy extract. Count nulls, out-of-range values, orphaned records, duplicate parties and accounts whose status combinations are not valid in the target state machine. Each finding goes into one of three buckets: fix at source before migration, transform during migration with a documented rule, or migrate as an exception with a manual work item. The goal is that no record is silently altered; every transformation is logged with the rule that caused it.

Trial loads should be repeated, not one-off. A common pattern is a series of full-volume dress rehearsals, each loading the entire cohort into a production-like environment, running the reconciliation suite, and recording elapsed time, defect counts and exception volumes. The defect curve should fall with each rehearsal; if it plateaus, the mapping logic has a structural gap that more rehearsal will not fix.

What the migration must preserve

Balances are the obvious item. Less obvious are the things that make a balance explainable: transaction history (how much is migrated, and in what form), accrued but unposted interest, pending items and holds, standing orders and direct debit mandates, limits, tax and regulatory attributes, and the audit trail itself. Regulators and customers expect continuity, so a statement showing a balance without history, or a mandate that silently disappeared, is a customer-facing defect even if the arithmetic is right.

Regulatory retention is a separate constraint. Some history may need to remain queryable in the legacy system or an archive for statutory periods after decommissioning, which affects when the old platform can truly be switched off. Plan the archive as a deliverable, with access controls and a retrieval service-level agreement, rather than as an afterthought.

Cutover rehearsal arithmetic

The cutover window is a budgeted resource, and the budget is arithmetic. The outline: freeze, extract the final delta, transform, load, reconcile, flip routing, smoke-test, release. Each step has a measured duration from rehearsal, and the sum must fit inside the window with margin and a rollback decision point.

An illustrative example, with numbers chosen only to show the method. Suppose the cutover window for a cohort is 10 hours overnight. Rehearsals show: freeze and final extract 45 minutes, transformation 90 minutes, bulk load 120 minutes, reconciliation 75 minutes, routing flip and smoke tests 40 minutes, for a total of 370 minutes (about 6.2 hours). That leaves roughly 3.8 hours of slack. A go/no-go checkpoint is set at the end of reconciliation, which means the rollback decision must be taken by hour 5 and the rollback itself, measured at 150 minutes, must still complete before the window closes. The latest safe decision time is therefore 600 minus 150 equals 450 minutes from start, and the reconciliation ends at 330 minutes, leaving 120 minutes of decision margin.

The method generalises. Take the slowest credible rehearsal, not the average. Add the measured rollback duration to the decision point. Treat the margin as the minimum you can tolerate, not a buffer to spend. And note that duration scales with volume: if the next cohort is three times larger, the bulk load and reconciliation steps do not simply triple if they hit I/O or locking limits, so rehearse at the target scale rather than extrapolating.

Rollback is a design requirement

A rollback is only real if, after the flip, the old core stays up to date or can be caught up. Two approaches are common. In reverse synchronisation, postings made on the new core after cutover are replayed to the legacy core so that it remains a viable fallback for a defined period. In forward-only designs, rollback is possible only until the first customer-visible posting on the new core; after that the plan is to fix forward. Reverse synchronisation is expensive and brittle, because it demands that the legacy core accept inputs from a system it was never designed to listen to. Forward-only is cheaper but demands very high confidence at the gate, which is why the rehearsal programme is so heavy.

Whichever you choose, state it explicitly, name the point of no return, and test the rollback at least as thoroughly as the cutover. Many programmes rehearse the happy path ten times and the rollback once.

ISO 20022 Coexistence and the Payments Edge

Core modernization and payment-format modernization are separate programmes that collide in the middle. Many banks need to be ISO 20022 ready for cross-border and domestic clearing at the same time as they migrate cores, and the two efforts compete for the same engineers and test windows.

ISO 20022 is a rich, structured XML-based messaging standard that replaces older formats such as the SWIFT MT series for many payment flows. In the SWIFT CBPR+ (Cross-Border Payments and Reporting Plus) programme, a period of coexistence in which both MT and MX (ISO 20022) messages were accepted ran for several years and was scheduled to end in November 2025 for the core payment instructions. Domestic high-value systems have also moved or are moving, including Fedwire in the United States, CHAPS in the United Kingdom and TARGET services in the euro area; confirm the status of each scheme you use against that scheme’s own publications, because migration dates and message scopes have been revised more than once.

For the core, the practical consequence is that data richness has to be preserved end to end. ISO 20022 carries structured party names and addresses, remittance information, purpose codes and regulatory data. A legacy core that stores a name and address in a few fixed-length fields will truncate or flatten that information, which may degrade sanctions screening, reconciliation and compliance reporting. The anti-corruption layer is again the right place to handle it, translating between the legacy field set and a richer canonical payment model.

Where payment translation should live

Two designs are common. In the first, a central payments hub owns all ISO 20022 handling and talks to the core with a simpler internal interface. In the second, each core speaks ISO 20022-derived messages directly. The hub design decouples scheme change from core change and lets you migrate cores without re-certifying scheme connectivity each time, which is a strong argument in a strangler programme. The cost is a new component that must itself be resilient, and a canonical model that must be rich enough not to throw away information the schemes carry.

Card networks add another thread. Card authorisation still runs on ISO 8583 in most deployments, with their own mapping to the core’s posting model; the differences between ISO 8583 and ISO 20022 and what each preserves are laid out in the guide linked in the context section. During migration the card processor needs to find the right core for a given card account, which again points to a routing facade sitting upstream of both cores, or to a shared account lookup service.

Coexistence is a test matrix

Because new and old cores will both receive and emit scheme messages for years, build a test matrix that crosses message type, scheme and core. A payment may arrive from the scheme, be routed by the facade to the correct core, post, produce a status message and an end-of-day statement, and each leg must behave identically whichever core owns the account. Automate this as contract tests that run on every change; manual regression across two cores and several schemes does not scale.

Operational Resilience, DORA and Failure Modes

A migration is a period of elevated operational risk, and regulators treat it that way. In the European Union, the Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies to most regulated financial entities from 17 January 2025. It sets requirements for ICT risk management, ICT-related incident classification and reporting, digital operational resilience testing (including threat-led penetration testing for certain entities), management of risk from ICT third-party providers, and an oversight framework for providers designated as critical. The text is available on EUR-Lex, and the European Supervisory Authorities have published technical standards that specify details such as the register of information on contractual arrangements.

For a core programme, the relevant implications are concrete. New vendors and cloud providers become ICT third parties that must be recorded, assessed and covered by contractual provisions. Services supporting critical or important functions need documented exit strategies, which is awkward for a platform that you are building your future on. Major incidents during cutover may be reportable, and testing evidence (rehearsals, failover tests, rollback tests) becomes part of your compliance story rather than only an engineering practice. Other jurisdictions have comparable regimes; the United Kingdom has its own operational resilience framework with impact tolerances for important business services. Confirm applicability and exact obligations with your compliance function, since they depend on entity type and jurisdiction.

Figure 4: Common failure modes in a legacy core migration, the mitigation for each, and how together they produce the evidence an operational resilience regime expects.

Failure mode: dual-write drift

If the facade writes to both cores independently, any partial failure leaves them diverged: the old core confirmed, the new core timed out. Retrying blindly may double-post. The mitigation is to treat one core as authoritative, send the second a derived, idempotent instruction through the event backbone (via the outbox rather than a synchronous dual call), and let the reconciler detect drift. Avoid distributed transactions across a mainframe and a cloud ledger; the failure modes are worse than the problem they solve.

Failure mode: hidden batch dependencies

Legacy cores hide dependencies in their batch schedules: jobs that run after interest accrual, extracts that feed finance, files dropped to an SFTP location for a partner. When a product moves, these implicit consumers silently stop receiving data. Inventory them through job-scheduler analysis, file-transfer logs and interviews with operations staff, and treat each as an interface that needs an owner and a replacement. Month-end and year-end processing in particular tend to expose dependencies that daily runs do not.

Failure mode: semantic drift in the new model

A rules-compatible but semantically different product (a different day-count, a subtly different fee waiver condition) will pass many tests and fail on real customers. Mitigate with replay of real historic activity, product-owner sign-off on behaviour for edge cases, and a catalogue of product rules written down and tied to automated tests.

Failure mode: cutover overrun and decision paralysis

When a cutover window is slipping, teams under pressure hesitate to roll back. Defining the go/no-go criteria and the owner of the decision in advance removes the ambiguity. Rehearse the decision as well as the technology: a table-top exercise in which the decision owner must call it based on a prepared dashboard is cheap and revealing.

Failure mode: vendor and platform concentration

Replacing a fragmented legacy estate with one new platform can concentrate risk. Mitigate through contractual and architectural exit options: data export in open formats, a canonical model owned by the bank rather than the vendor, ISO 20022-neutral payment interfaces, and an honestly tested plan for operating without the vendor’s managed service for a defined period. This is the area where operational resilience regulation and good architecture agree.

Trade-offs, Gotchas, and What Goes Wrong

The honest list of limits is longer than most vendor decks admit.

The strangler is not free. Running two cores plus a facade, an anti-corruption layer and a reconciler means paying for three systems of integration for years. Programmes that cut the reconciliation budget to save money tend to discover breaks in production instead. If your estate is small and the legacy core is genuinely unsupported, a well-rehearsed bounded big-bang may be the lower-risk path, and it is a legitimate choice for a small bank with a simple product set.

Event-driven does not mean eventually consistent balances. Teams sometimes extend asynchrony into the posting path and then spend months explaining negative available balances to customers. Keep balance-affecting decisions inside the ledger’s consistency boundary and use events for propagation.

The facade can become a monolith. Because it knows about every product and every core, it attracts logic. Keep it a router and enforcer of cutover state; push business behaviour to the cores and the hub. A facade that accumulates exceptions becomes the new legacy.

Migration of the least interesting data is the longest pole. Closed accounts, dormant balances, deceased-customer estates, disputed items and unusual legal structures are low-volume and high-effort. Plan for them in the schedule, with named owners, instead of discovering them in the last cohort.

Operational readiness is not engineering readiness. Contact-centre scripts, branch procedures, finance close, reconciliation operations, fraud rules and regulatory reporting all change when the core changes. A successful data cutover with an unprepared operations team still produces an incident. Treat operations training and tooling as deliverables with their own acceptance criteria.

Do not trust a single environment. Performance issues often appear only at production volume, with production data skew and production integration latencies. A representative performance test, including the end-of-day equivalent on the new platform and the month-end peak, belongs on the critical path.

Over-customising the new core recreates the old one. Composable and configurable platforms are only as clean as the discipline applied to them. Every bespoke extension should justify itself against configuring the product, and extension code should be treated with the same release rigor as the product.

Talent and knowledge are single points of failure. The few people who understand the legacy core are the programme’s most valuable and most fatigued resource. Capture their knowledge as executable artefacts (mapping tests, replay suites, runbooks) early, while they are still around and willing.

Practical Recommendations

Start by deciding the end state in one sentence, including where the ledger of record lives and what happens to the legacy core. Without that, every other decision drifts. Then choose the smallest slice that exercises the whole machinery, such as a new product or an internal cohort, and use it to prove the facade, the anti-corruption layer, the outbox and the reconciler before touching a mainstream book.

Invest disproportionately in reconciliation and replay. Those two capabilities are what convert the migration from a leap of faith into a measurable engineering process. Define tolerances in business terms before the first parallel run, and put the decision gate in writing.

Treat regulatory and vendor risk as architecture inputs from the beginning. Map third-party dependencies, plan exit routes, and build the evidence trail for rehearsals and rollbacks as you go. Finally, keep the programme honest about time: a progressive migration is a multi-year effort, and its credibility comes from delivering safe, boring cutovers on a predictable cadence.

Checklist

Write the target state: ledger of record, systems to retire, archive plan and dates.
Build the routing facade with an auditable, reversible per-account ownership flag.
Implement an anti-corruption layer with versioned, tested mappings.
Publish events through a transactional outbox; use change data capture on the legacy side.
Give every instruction a stable correlation id and make the ledger idempotent.
Stand up the reconciler as a product with break families, tolerances and case management.
Profile legacy data; log every transformation; repeat full-volume trial loads.
Time every cutover step in rehearsal; compute the latest safe rollback decision point.
Decide reverse synchronisation versus forward-only, and name the point of no return.
Keep ISO 20022 handling in a payments hub with a rich canonical model.
Record third-party dependencies and exit plans; retain testing evidence for regulators.
Train operations, finance and contact-centre teams before each cohort.

Frequently Asked Questions

What is core banking modernization?

Core banking modernization is the replacement or re-architecture of the system of record that holds accounts, balances, products and postings. It typically means moving from a monolithic, batch-oriented legacy platform to a more modular, API- and event-driven core, usually in stages. The work includes data migration, integration changes, payments adaptation, operational readiness and regulatory assurance, not only new software.

What is the strangler fig pattern in banking?

The strangler fig pattern places a routing facade in front of the legacy core and gradually moves accounts, products or functions to a new core behind it. An anti-corruption layer translates between the two models. Because traffic is redirected in small, reversible steps, the bank avoids a single high-risk cutover, and the legacy system is retired once nothing depends on it.

Is big-bang or progressive migration safer for a core system?

Progressive migration is generally safer for large, complex banks because failures are small and reversible, but it costs more in parallel running and extra infrastructure. A bounded big-bang can suit small institutions with simple products and an unsupported legacy platform. The decision should weigh failure impact, rollback feasibility and rehearsal capability, not preference or fashion.

What does composable core banking mean?

Composable core banking splits the monolithic core into independently deployable components such as product engine, ledger, payments, limits and customer data, connected by APIs and events. The aim is to change or replace one capability without redeploying everything. It requires disciplined interface contracts, a clear ledger of record and strong governance to avoid recreating a distributed monolith.

How do banks reconcile old and new cores during a parallel run?

Both cores process the same instructions, each stamped with a shared correlation id, and a reconciliation service matches postings and end-of-day balances by business key. Breaks are classified into timing, rounding, semantic and data families, measured against pre-agreed tolerances and resolved through case management. Only when the break trend stays within tolerance does a cohort move to cutover.

Does DORA affect core banking migrations?

For EU financial entities in scope, DORA (Regulation (EU) 2022/2554, applying from 17 January 2025) sets requirements on ICT risk management, incident reporting, resilience testing and third-party risk. A migration introduces new ICT providers, cutover incident risk and testing evidence needs, so it should be planned with compliance. Applicability depends on entity type, so confirm with your compliance team.