Modernizing Core Banking Without a Big-Bang Rewrite

FinTech Engineering

Core-banking modernization succeeds when it moves one owned capability at a time, preserves financial truth, and makes every migration checkpoint reversible. I start with the critical operation, not a fashionable target architecture; the migration examples below are synthetic.

Define the critical operation before the target architecture

Begin with the customer or business operation that must remain available: posting a transfer, calculating interest, servicing a loan, or producing a statement. Map its data, batch dependencies, downstream reports, manual controls, and recovery objectives. The Basel Committee’s Principles for Operational Resilience call for identifying critical operations, mapping dependencies, setting tolerances for disruption, and testing the ability to stay within them. Those principles apply directly to banks; they are also a disciplined frame for any regulated modernization.

A service decomposition is not the objective. The objective is to change a capability without losing balances, contractual behavior, audit evidence, or recoverability. A modular monolith may be a better destination than microservices if it gives clear ownership with lower operational cost.

Choose a bounded migration slice

The AWS strangler-fig pattern describes routing requests through a façade while new components incrementally replace old functionality. Its value is controlled scope, not a guarantee of safety.

Select a slice with a coherent business boundary and measurable exit criteria. “Customer profile” can still be unsafe if dozens of legacy jobs update it. “Read-only statement history for accounts opened after a cutoff date” is often easier to own. Document:

• commands and queries in scope;
• source of record for every field and business date;
• allowed writers during each phase;
• reconciliation and acceptance thresholds;
• rollback procedure and maximum rollback age;
• legacy dependencies that must be removed before completion.

Never leave “temporary” dual write as an architectural assumption. Two systems accepting independent updates create conflicts that timestamps cannot reliably solve. Prefer one authoritative writer, with changes propagated through a transactional outbox or controlled replication. If dual write is unavoidable for a short phase, define conflict ownership, failure handling, and a hard removal date.

Isolate legacy semantics

Legacy interfaces often encode product rules in field names, batch timing, or error codes. Do not spread those semantics into every new service. An anti-corruption layer translates between the legacy model and the modern domain boundary.

The layer should be intentionally narrow. It validates requests, maps identifiers and values, preserves the original reference, and exposes uncertainty rather than inventing success. Version mappings and test them against recorded, anonymized or synthetic cases. If it grows into a second core containing business policy, the migration has merely moved the monolith.

Separate data movement from authority transfer

Copying data does not make the destination authoritative. Treat migration as distinct stages:

1. baseline: inventory and checksum the source population;
2. backfill: copy historical data with transformation lineage;
3. catch-up: apply ordered changes after the baseline point;
4. shadow read: compare outputs without serving customers;
5. controlled cutover: route a defined cohort or capability to the new owner;
6. stabilize: monitor, reconcile, and retain a tested rollback path;
7. decommission: remove legacy writers, jobs, credentials, and data copies.

Change-data capture can support catch-up, but it does not explain business meaning. Deletes, out-of-order records, schema changes, and updates performed outside the captured log all need handling. Record a migration watermark and prove that every source change before it is present once in the destination.

For financial records, compare more than row counts. Reconcile opening and closing balances, transaction counts and amounts by currency, posting dates, account states, and independently computed control totals. Differences become owned cases; they are not automatically “fixed” by copying the latest value.

Make routing and rollback observable

The façade should emit the capability, cohort, chosen backend, rule version, operation identifier, latency, and outcome. A feature flag alone is not a migration control. Routing changes need approval, staged rollout, and an auditable history.

Define rollback before cutover. If the new system has accepted writes, switching traffic back may require replaying those facts into the legacy system or choosing forward recovery instead. A rollback plan that says “turn off the flag” is valid only while the legacy side remains complete and compatible.

Test failure during backfill, lag in replication, a poison record, schema drift, legacy batch overlap, a partial cohort cutover, and loss of the façade. Rehearse with production-shaped synthetic data and a clock that crosses end-of-day and month-end boundaries.

Know when the slice is finished

A capability is not modernized while the legacy system still computes its results, repairs its data, or remains the only recovery path. Exit criteria should include no legacy writers, reconciled history, operational runbooks, demonstrated recovery, performance within objectives, trained support teams, retired credentials, and a retention decision for old data.

Track business outcomes: change lead time, incidents, reconciliation breaks, recovery time, manual work, and cost per operation. Counting new services rewards movement rather than improvement.

The modernization decision

Use a façade to control traffic, an anti-corruption layer to contain old semantics, one writer to preserve authority, and explicit checkpoints to move data and responsibility separately. Modernization is complete only when a bounded capability has one clear owner and the obsolete path can be removed. The safest program is not the one with the most ambitious target diagram; it is the one that can explain and reverse each step without compromising financial truth.

Related reading

• ISO 20022 as a Domain Model, Not an XML Problem
• Real-Time Fraud Decisions Under 100 Milliseconds

References

• AWS — Strangler fig pattern
• AWS — Anti-corruption layer pattern
• Basel Committee — Principles for operational resilience