Adjacent vs replacement: why bank-core projects fail at month 18.

Three anonymous EU core-banking-replacement projects, post-mortem. Pattern: ledger cutover collapses under dual-run cost and regulator anxiety. The adjacent pattern — read-only on legacy, build new on Coreal — does not have the same failure mode. Why.

Three core-replacement post-mortems

Every CEE bank CTO I have ever spoken to has at least one of these on the team's CV: a multi-year core-banking-replacement programme that went off track at month 16, 18 or 22. The board agreed to a Mambu migration, or a Thought Machine cutover, or a Temenos R23 upgrade pretending to be a re-platform. €20–80M was spent. After two years the new system handles 5% of new accounts. Three years in, the question of whether the old system can be turned off is being quietly deferred to the next strategic plan.

I have personally seen this happen three times in EU/CEE between 2019 and 2024. The exact banks, sizes and vendors are anonymised here because the lesson is structural, not name-and-shame. But the pattern is so consistent that it deserves its own essay.

Bank A — universal bank, ~€100B assets, six CEE markets. Decision in 2019 to migrate from a legacy on-premise core to a cloud-native vendor (one of the well-known names). Target: full cutover in 30 months. By month 18, only the first cohort of new accounts was opening on the new core. Branch staff were trained twice — once on the new vendor, then re-trained when the schedule slipped and they had to keep using the legacy. Project formally re-scoped at month 22 to "platform of choice for new products" rather than full migration. By month 36, the new vendor was a parallel system handling roughly 8% of customer count and 3% of transaction volume. Programme officially closed at month 42 as "Phase 1 complete." Phase 2 has been deferred three times.

Bank B — neobank-challenger, ~€10B assets, single market. Decision in 2020 to migrate from a homegrown system (with known scaling issues) to a vendor with a hosted core. Target: 12-month cutover. The bank's customers were younger and digital, so the bank assumed the cutover risk was lower than for a universal. At month 8 the regulator (national competent authority in the bank's home country) raised concerns about the dual-run cost being absorbed by capital adequacy. The bank had budgeted €4M for migration but the dual-run year was running at €1.2M/month. Project was paused at month 14, restarted at month 22 with a smaller-scope vendor (one of the configurable Java-based cores). At time of writing, three years in, the bank is still running both systems and accepting it as the steady state.

Bank C — tier-1 universal, ~€200B assets, single market, deep history. Decision in 2021 to incrementally rebuild the core using a modern stack in-house. Target: 36-month rebuild with parallel running for the last 12 months. By month 28 the in-house team had built 60% of the read paths but 15% of the write paths. The bank's CTO left at month 30. The new CTO scoped the in-house rebuild down to a "modern API layer in front of the legacy" — i.e., abandoned the rebuild as a rebuild. The legacy core remains the book of record. The modern API layer is now in production and is, in fact, useful — but it took 36 months of programme spend to discover that the legacy core was not the bottleneck.

Three different vendors. Three different strategies (vendor SaaS, vendor on-prem, in-house). Three different bank sizes. Identical pattern of failure: the cutover does not happen.

The structural pattern

The cutover is the single point of failure in every core-banking-replacement programme. Around it, three forces converge:

1. Dual-run cost compounds

For the period the bank runs both systems in parallel — and you cannot cut over without parallel running — the bank pays for both. Vendor licensing on the new system. Operations on the legacy. Reconciliation between the two (because they have to agree). Risk of drift between the two ledgers (because they cannot perfectly agree). Compliance overhead doubled, because both systems are in scope for AML, sanctions, regulator audit.

Most programmes plan for 3–6 months of parallel run. Most programmes end up with 18–36 months of parallel run, because the cutover keeps slipping for the other two reasons below.

A programme that hoped to save the bank €20M/year on the legacy is, by month 24, costing the bank €15M/year on dual-run. Net: −€35M/year vs the plan.

2. The data is heavier than it looks

The bank's legacy core has 20–40 years of accumulated state. Open accounts. Closed accounts that may need to be reopened. Suspended accounts under regulator order. Custody arrangements. Trust account structures. Power-of-attorney records. Garnishment orders. Cross-account interest setoffs. Customer letters that map to specific products that no longer exist but still hold balances.

A new core's data model is clean and rational. It does not know about closed-but-recoverable accounts from 2003. The migration team's first job is to write transformation rules for every one of those legacy data shapes. Most banks underestimate this by 4–6×. By month 12, the migration team has done 60% of the transformation rules and 95% of the transformation rules they care about. The remaining 5% — the long tail of weird historical data shapes — takes the next 12 months.

The regulator does not let you leave those long-tail records in the old system if you have declared the new system the primary one. They have to come across, correctly. The team needed to do it is the same team building the new system, which is now competing with itself for hours.

3. Regulator anxiety compounds

A bank doing a core-banking cutover is, from the regulator's perspective, replacing the system that holds all the customer state, all the AML/sanctions risk, all the audit trail. The regulator's risk department has every incentive to slow this down. They will not say no — but they will request more evidence. They will request dry-run results. They will request scenario testing. They will request a parallel-running period extended beyond the bank's plan.

Each regulator request is reasonable. Each one adds 4–8 weeks. By month 18, the bank has had six regulator-driven schedule extensions, and the migration team is exhausted from packaging the same evidence in different formats six times.

The regulator never officially blocks the cutover. The cutover just never happens.

The adjacent pattern

The adjacent pattern says: the cutover is the failure mode, so do not do a cutover. Leave the legacy core as the book of record for existing customers and existing balances. Build new products on a new ledger — Coreal — alongside the old core. The two coexist, and over time the new system handles more and more of the bank's transactional volume, but there is no single date on which the bank "moves to" the new system.

The architectural shape is simple:

• Existing customer record, existing balances, existing transaction history: legacy core (T24, Mambu, Profile, FIS, whatever).
• Read-only feed from the legacy into Coreal — DBA-approved read-replica, vendor-supported message-queue subscribe, or T+1 batch — for new product flows to know what state the customer is in.
• New product flows (new card-to-card payment rails, new FX, new savings products, new crypto-buy, new card issuance): on Coreal ledger.
• Customer-facing UX: composed from both, but the bank's brand and the bank's banking licence sit on top of both as a single coherent product.
• Reconciliation pattern: every Coreal ledger entry that touches an existing legacy account writes back via the vendor's standard write-path on T+0 (real-time) or T+1 (batch, depending on operation type). The legacy core stays authoritative. Coreal is the operational ledger.

In Wave-1, this means modernised KYC orchestration (field note). KYC files live on Coreal. The legacy core's customer master is read for existing customer state, written to only when an account is opened.

In Wave-2, the bank ships card-to-card transfers, FX, and possibly crypto-buy on the Coreal ledger. The bank does not have to staff a new fintech team for each product; the Minctrl pipeline ships them. Each product is an extension of the same Coreal ledger, not a separate sub-platform.

In Wave-3 (months 12–36), the bank's new-product volume grows. Crucially, new customers can open accounts on Coreal directly; the legacy core is consulted for compatibility but no longer required for new customer state. Over time, the legacy core's read-write share drops to read-only. The bank has not done a cutover.

Why this avoids the failure mode

On dual-run cost: there is no dual-run. The two systems are not running the same product on the same customer. They are running different products on the same customer, with the legacy authoritative for the old, the new authoritative for the new. The bank pays for both because they are doing different things — that is acceptable spend, not duplicate spend. The cost line is not waste; it is the cost of new product launches.

On data weight: the new system does not need to absorb the legacy's 20–40 years of accumulated state. It needs to read the parts it cares about for new product flows, and write new state for new flows. The long-tail historical records stay where they are. The bank never has to write transformation rules for closed-but-recoverable accounts from 2003.

On regulator anxiety: the regulator is not being asked to approve a system replacement. It is being asked to approve a new product launch under the bank's existing licence, with a documented ICT third-party (Coreal) under DORA Art. 28 (see the evidence pack). This is a regulatory pattern the regulator is comfortable with. The bank's outsourcing register expands. The audit and assurance scope grows. But there is no "cutover" to delay.

By design, the adjacent pattern does not have a single point of failure that the dual-run cost / data weight / regulator anxiety triad can attack. There is no cutover date for them to converge on.

What the adjacent pattern does not solve

I should be specific about what is not claimed.

The legacy core is still there. It still costs what it costs. Its vendor still charges what they charge. If the bank's strategic ambition is to retire the legacy vendor and stop paying their licence fees, the adjacent pattern does not do that. It defers the legacy retirement decision.

In practice, what we have observed in our partner banks is that the legacy core, once it is no longer the platform of growth, becomes much easier to retire on a 5–10 year horizon. The retire-the-legacy decision in year 6 is structurally easier than the migrate-to-the-replacement decision in year 2, because the legacy is no longer doing customer acquisition, no longer doing new products, and is increasingly just servicing a shrinking book of legacy customers. At that point the migration of the residual book is a much smaller programme than a full cutover.

Some operations on existing customers still need legacy writes. The bank cannot run, say, an interest accrual on an existing legacy account from Coreal. That has to stay where the account is. The adjacent pattern means the bank still has to maintain the legacy as a working system for existing flows. There is no escape from that.

Two systems means two operational concerns. The bank's SRE / operations team has to monitor both. Two on-call rotations, two incident-response taxonomies, two failure modes. We mitigate by giving the bank a consolidated incident webhook (covered in the DORA Art. 28 evidence pack), but the operational load doubles relative to a single-system bank. We claim the doubling is worth it; we don't claim it doesn't exist.

When replacement is still the right call

The adjacent pattern is not the answer to every bank's question. There are three cases where a true core replacement is still the right strategic call:

1. Greenfield bank. A new bank with no legacy customers and no legacy core can pick a modern core and run it as primary. No adjacent layer needed because there is no legacy to be adjacent to.

2. Single-product bank. A bank whose entire business is a single product line — a private bank with only HNW custodial accounts, say — can replace the core in a 12–18 month programme because the data and product surface area is narrow.

3. Legacy vendor exit. If the legacy vendor has announced end-of-support on a specific date and the bank cannot stay on it, the migration is forced. In that case, the question is not "should we migrate" but "what's the lowest-risk path", and a phased cutover with intermediate vendor is sometimes the only option.

For the tier-1 universal CEE bank — the most common Coreal partner profile — none of these three cases apply. The adjacent pattern is the right call.

The strategic line

I have come to think the choice between adjacent and replacement is not a technical choice. It is a strategic one about what the bank's ambition is.

If the ambition is "replace the legacy stack", the bank is committing to a 3–7 year programme with a high-probability single point of failure (the cutover). If it succeeds, the bank gets a modern core. If it doesn't (the historical base rate is bad), the bank has spent €50–100M and has a parallel system that handles 5% of volume.

If the ambition is "ship new products at neobank cadence without abandoning the existing customer book", the bank does not need to replace the core. It needs to put a new product engine alongside it. The Coreal pattern. Wave-1 in 90 days. Wave-2 in months 4–12. The legacy retires when it retires, on its own clock, without a forcing function.

Both ambitions are legitimate. The choice depends on what the bank is being judged on. The bank's CEO judged on ROE next year cares about the latter. The bank's CEO with a strategic plan written in 2018 around "digital transformation by 2024" cares about the former.

Most boards I have talked to in 2024–2025 are quietly migrating their ambition from the former to the latter. The empirical base rate of core replacements convinced them. The adjacent pattern, until recently, did not exist as an integrated offering, so they didn't have an alternative. Now they do.

Engagement-side disclosure: I am the founder of Coreal, which offers the adjacent pattern as a product. The pattern existed in pieces (in-house API layers, vendor add-on modules, scattered fintech BaaS providers) before us. Coreal's contribution is packaging it into a coherent product with the ledger, BPM, KYC orchestration and AI orchestrator unified, plus the DORA / AMLA / MiFID II compliance perimeter as a baseline. For the architectural detail, see solutions for banks. For a Wave-1 brief scoped to your specific core platform, book a working session →