Modernize without a big bang: The strangler pattern for core banking

A core replacement concentrates product, data, integration, accounting, operations, customer, vendor, and control risk into one program. The strangler pattern changes that risk profile by introducing a governed boundary around the legacy platform and moving selected capabilities to the target environment over time.

Strangling is a retirement strategy, not another integration layer

The pattern only creates value when each increment removes a defined responsibility from the legacy core. If new services merely copy data and add interfaces while the old platform remains authoritative for every decision, the bank has increased complexity without reducing dependence.

Each release should name the capability being moved, the new system of record or decision authority, the legacy behavior being disabled, and the conditions required to retire associated code, data movement, procedures, and vendor services.

Choose boundaries the bank can operate

Sequence around value and reversibility

The first increment should be material enough to prove the architecture but bounded enough to operate safely. Favor capabilities with visible customer or operating value, understood data, manageable accounting consequences, and a reversible cutover. Avoid beginning with a dependency that requires every downstream process to change at once.

A release sequence may begin with read-oriented access or a contained digital journey, then move decision logic, orchestration, servicing, posting, and ultimately the authoritative record. The exact order depends on the core, product structure, integration options, vendor terms, and the bank's capacity to reconcile and support parallel operation.

Make coexistence an explicit temporary state

During migration, old and new platforms may both participate in a transaction or customer journey. Document which platform owns each state transition, how events are ordered, how duplicate or late messages are handled, and how teams reconcile financial and customer records. Establish service levels and limits for coexistence so it does not become the permanent architecture by default.

Control cutover with evidence, not confidence

Acceptance evidence should cover functional behavior, data completeness, accounting and reconciliation, security, performance, resilience, regulatory controls, customer communications, procedures, training, monitoring, incident response, rollback, and vendor readiness. Define exit criteria before testing begins and retain the exact evidence supporting the release decision.

Measure whether legacy dependence is actually declining

• Capabilities and transaction volume moved to the target environment.
• Legacy interfaces, jobs, databases, reports, procedures, and licenses retired.
• Reconciliation breaks, exception volume, latency, availability, and customer impact during coexistence.
• Release frequency, change-failure rate, recovery time, and operating effort.
• Control exceptions, open risks, vendor dependencies, and cost avoided or incurred.

A practical first 90 days

1. Inventory critical capabilities, data, integrations, controls, operational dependencies, and contractual constraints.
2. Select one bounded capability and define target ownership, measurable value, retirement scope, and rollback conditions.
3. Design API and event contracts, identity, data authority, reconciliation, observability, resilience, and control evidence.
4. Build a production-like pilot with operational teams, security, risk, compliance, finance, and vendors involved in acceptance.
5. Release behind controlled routing, measure outcomes, close gaps, and retire the first legacy responsibility before expanding.