A staged approach to core banking modernization

The decision in this scenario

Imagine a bank whose core system must keep serving accounts while its product teams need to change one capability. The difficult question is not whether a new service can be coded. It is whether the bank can move a business operation without losing the meaning of balances, posting rules or audit evidence. This is a hypothetical design exercise, not a description of a client system.

A defensible starting approach

We would begin with a capability that has known callers and a result that can be reconciled, such as a read-only account view. A routing façade could direct that request to the old or new implementation while both coexist. Microsoft's Strangler Fig pattern supports this staged shape, but the façade adds another critical dependency and does not resolve data ownership by itself.

Evidence: Microsoft Azure Architecture Center: Strangler Fig pattern

Prove the boundary before extracting writes

Map every caller, batch job and downstream report that depends on the chosen capability. Compare outputs using the same inputs and agree on acceptable differences before shifting users. A read-only first slice is useful for learning about routing and observability, but it is not evidence that deposits, transfers or reversals can safely move next.

For a write path, designate one authoritative writer at each stage. If events are mirrored to a new store, define ordering, replay and reconciliation rules. An unexplained difference in account state is a stop condition, not a rounding error to be absorbed into a launch report.

Evidence: Microsoft Azure Architecture Center: Strangler Fig pattern

Design recovery around business state

Traffic can be routed back quickly; financial state cannot always be rolled back the same way. The runbook needs to distinguish a request that never committed from one that committed but lost its response. That distinction determines whether the recovery action is retry, reconciliation or a controlled correction.

The tradeoff is slower apparent progress in exchange for evidence. Keeping two systems live also increases operational complexity, so every migrated slice needs an exit criterion for retiring its legacy path. The team should not promise an instant full rollback once irreversible writes have occurred.

What the team would need to build and prove

• Domain and dependency mapping of the existing monolith
• API gateway and routing layer to run old and new paths side by side
• Incrementally extracted services with independent deployment
• Staged data migration with verification and rollback at each cut
• Audit-oriented logging and tracing across both paths

What success would mean

In this hypothetical scenario, success would be one bounded capability with reconciled results, an owned operating path and a documented recovery limit. Only then would the next, riskier capability be selected. No delivery result or client metric is being claimed.