For mid-market banks, the safest core banking modernization strategy is no longer a full platform replacement. It is progressive modernization: stand up a modern core in a sidecar alongside the legacy ledger, route a defined segment of new business to it, prove it under production load, then migrate the existing book in controlled waves. Bain research across more than 45 core banking programmes identifies this incremental approach as one of the strongest predictors of a successful core replacement (Bain & Company).
The pressure to act is real, and most banks know it. In the American Bankers Association 2024 Core Platforms Survey, satisfaction with core providers falls steadily through the contract term and reaches its lowest point at renewal, yet only about 19 percent of banks say they are likely to convert at their next renewal date (ABA Banking Journal). That gap between dissatisfaction and action is not preference. It is fear of a migration that takes down the bank. This post lays out how mid-market banks close that gap without betting the franchise.
Key Takeaways
- Progressive modernization, not big-bang replacement, is the dominant pattern. Bain ranks it as a top predictor of successful core replacement across 45+ programmes.
- The sidecar strategy runs a modern core in parallel with the legacy ledger for a defined segment. IDC projects 40 percent of banks will use sidecar approaches by 2026, rising to 70 to 80 percent by 2028.
- Legacy is a budget problem, not just a feature problem. Roughly 90 percent of US banking core software is considered legacy, and legacy maintenance can consume up to 70 percent of IT budgets.
- Programmes fail on data migration, integration breadth, and transition governance, rarely on the platform itself. Most banks underscope all three.
- In the UAE, CBUAE FIT Programme initiatives like the Aani Instant Payments Platform raise the operational tempo, so modernization timelines have to be planned against the regulatory calendar.
Core banking platform: the system of record that holds accounts, balances, and the ledger, and that processes deposits, withdrawals, loans, and payments. Almost every other banking system depends on it.
Why legacy core banking has become a budget problem, not just a feature problem
Roughly 90 percent of banking core software in the United States is now considered legacy. At many institutions, maintaining those systems consumes up to 70 percent of the IT budget, and the engineers who understand COBOL, IMS, and the surrounding batch tooling are retiring faster than they can be replaced. Every dirham or dollar spent keeping a legacy core alive is a dirham not spent on new products.
The deeper issue is architectural. Legacy cores were built for overnight batch processing in a branch-led world. They were never designed for the integration density that customers and regulators now expect: dozens of API calls in a single mobile session, real-time fraud screening, instant settlement, and continuous regulatory reporting. A core that supports T+1 settlement in a market moving toward real-time will lose product races and create regulatory friction at the same time.
In the UAE that tempo is set centrally. The Central Bank’s Financial Infrastructure Transformation (FIT) Programme has put live the Aani Instant Payments Platform, advanced the Digital Dirham through cross-border and domestic pilots, and built a sovereign financial cloud (CBUAE). Federal Decree-Law No. 6 of 2025 then unified banking, fintech, and insurance under a single regulatory framework. A legacy core that cannot keep pace with instant payments and open finance is no longer just an IT constraint. It becomes a board-level conversation.
What a modern core banking platform actually changes
A modern core is built around three shifts: cloud-native deployment, microservices-based product engines, and API-first integration. Together they produce operational characteristics legacy cores cannot match. Product configuration changes land in days rather than quarters. High-traffic services scale independently without rebuilding the ledger. Product modules become hot-swappable. Real-time event streams feed analytics, risk, and AI systems natively instead of through overnight extracts.
The trade-off is a different way of designing products. Where legacy systems invited customization through embedded code, modern cores such as Mambu, Thought Machine, and the cloud-native variants of Temenos Transact push banks toward configuration-led product design. That feels restrictive at first. In practice it forces the standardization that legacy estates lost to accidental complexity over twenty years, and it makes the next round of regulatory or product change far cheaper to ship.
This is also where modernization connects to AI ambitions. A modern core that emits clean, real-time events is the data substrate that real-time fraud detection, embedded finance, and agentic AI use cases depend on. Without it, those programmes stall on data plumbing. The core is the foundation the rest of the roadmap stands on.
The sidecar strategy: how most mid-market banks now modernize
Sidecar strategy: running a modern core in parallel with the existing legacy core, where the new core handles a defined subset of customers, products, or services while the legacy core keeps running the existing book.
The sidecar is now the default pattern for mid-market core banking modernization. The legacy core continues to run the existing book while the modern core takes new originations or a pilot segment. The bank captures most of the upside of a modern platform while limiting the downside of a catastrophic migration. IDC projects that 40 percent of global banks will pursue sidecar strategies by 2026, rising to 70 to 80 percent by 2028 as the approach becomes standard practice.
Common sidecar use cases are digital-only product lines, real-time payments rails, lending books for new asset classes, and challenger sub-brands that test product ideas without exposing the parent franchise. Each phase proves value, demonstrates the platform under real load, and lets the legacy book migrate progressively rather than in a single risky cutover. This is the progressive modernization that Bain identifies as a leading predictor of success across more than 45 programmes.
The timeline matters for planning. A sidecar programme for a single domain typically runs 18 to 36 months, against three to five years for a full-platform migration. Decommissioning the legacy core almost always runs 12 to 24 months past original estimates. Two consequences follow. The total-cost-of-ownership models vendors present at sales stage rarely survive contact with reality. And banks should budget for an extended period of running two cores in parallel, with the operational and regulatory overhead that implies.
Where core banking transformation programmes actually fail
Failed programmes rarely fail because the new platform does not work. They fail because the bank underscopes three things, all of which sit on the bank’s side of the contract, not the vendor’s.
Data migration
Decades of financial history live in hierarchical or older relational databases, and schemas that made sense in 1995 do not map cleanly onto modern targets. A transaction reference field that legacy systems treated as a free-text comment may carry meaning that the new core rejects as invalid. Data cleansing has to start before vendor selection, not after, and it has to include validation runs against both source and target. The bank that discovers its data quality problem during migration testing has already lost the schedule.
Integration breadth
A legacy core in a mature bank typically has 200 to 400 integration points across payments, treasury, ERP, regulatory reporting, onboarding, fraud, and analytics. Every one has to be re-pointed, tested, and validated against the new core. Banks that scope only the obvious integrations and meet the long tail mid-project routinely lose six to twelve months. A full integration estate audit before vendor commitment is one of the highest-leverage activities in the entire plan, and one of the most frequently skipped.
Transition governance
Core migrations now qualify as elevated operational risk events under most supervisory frameworks, including those overseen by the CBUAE. A programme that reaches cutover during a capital requirement transition or a regulatory examination cycle compounds complexity that benefits neither the bank nor the regulator. Modernization timelines have to be sequenced against the regulatory calendar, not only against internal executive deadlines. In a market with the FIT Programme’s pace, that calendar is unusually full.
How core modernization connects to ERP and finance systems
Core banking modernization is almost never a self-contained project. The general ledger interface to the bank’s ERP, the regulatory reporting feeds, the treasury and liquidity systems, and the management information layer all have to be re-architected in the same window. Banks that treat the core swap as a back-end IT job and ignore the finance and reporting layers tend to find, six months later, that month-end close has broken in subtle ways that take a full quarter to debug.
The pattern that holds up is to run core, finance, and regulatory reporting as one coordinated programme rather than three procurements. ERP implementation services that understand banking workflows increasingly sit inside the modernization stack rather than beside it. Master data management across customer, product, and account dimensions becomes the connective tissue between the new core and every system that consumes its data. Banks that get this layer right inherit a clean reporting environment as a byproduct of modernization, which is often worth more than the core swap on its own.
A practical sequence for the first eighteen months
For most mid-market banks, a workable default looks like this. Begin with a six to nine month assessment that maps current-state architecture, the integration estate, data quality, and regulatory exposure. Use that assessment, not vendor decks, as the basis for selection. Pick a sidecar use case with clear product fit and a limited blast radius, such as a digital deposit product or a new lending vertical. Build an abstraction layer between the legacy and modern cores so downstream systems do not change every time a customer moves. Run the sidecar in production for at least twelve months before committing to broader migration, and use the operational data from that period to plan the next waves.
The discipline established in assessment, selection, and pilot compounds across every later wave. The reverse is just as true. Banks that compress phase one to hit an executive deadline spend the following four years paying for the shortcuts they took. Investing disproportionately in the first phase is the single most reliable lever in a modernization plan. Examples of how this sequencing plays out across transformation programmes appear in Kentro’s case studies.
What core banking transformation looks like done right
The banks that will lead in the UAE and broader MENA through 2030 are not the ones with the largest balance sheets. They are the ones already rebuilding their core architecture around real-time settlement, clean event data, and modular product engines. Cores that served well for two decades now constrain product velocity in ways that matter to retail customers, corporate treasurers, and regulators at the same time.
Modernization is not a single project. It is the capability that open banking, embedded finance, real-time fraud detection, and agentic AI all depend on. Banks that treat it as a multi-quarter operational redesign, with technology as one input among several, tend to ship working modern cores. Banks that treat it as an IT initiative tend to join the documented list of failed programmes. The difference is rarely the budget. It is how seriously the institution takes what the transformation actually requires.
Frequently asked questions
How much does a core banking modernization programme cost?
There is no fixed price, because cost is driven by scope: the number of integration points, the state of your data, how many product lines move to the sidecar, and how long the two cores run in parallel. A scoped sidecar pilot is a very different commitment from a full-estate migration. The most useful first step is an assessment that sizes the integration estate and data quality before anyone signs a platform contract. We are happy to scope this on a call.
How long does it take?
As a soft range, a sidecar programme for a single domain typically runs 18 to 36 months, while a full-platform migration runs three to five years. Decommissioning the legacy core usually extends 12 to 24 months past the original plan. Your actual timeline depends on integration breadth, data condition, and how the work is sequenced against the regulatory calendar.
What return should we expect?
Returns depend on your inputs, so we do not quote a fixed multiple. The value tends to show up in three places: lower legacy maintenance as a share of the IT budget, faster product configuration, and a cleaner data and reporting environment that downstream analytics and AI can use. Banks that run modernization as an operational redesign, rather than an IT swap, capture more of that value.
Is a sidecar strategy safer than a full core replacement?
For most mid-market banks, yes. The sidecar limits the blast radius by running new business on the modern core while the legacy core keeps serving the existing book, so a problem in the new platform does not threaten the whole franchise. IDC’s projection that most banks will adopt sidecar approaches by 2028, and Bain’s finding on progressive modernization, both point the same way.
Which core platforms do mid-market banks typically evaluate?
Cloud-native and configuration-led platforms such as Mambu, Thought Machine, and the newer cloud variants of Temenos Transact come up most often. The right choice depends on your product mix, deployment model, and integration requirements, which is exactly what the assessment phase is designed to determine before you commit.
How does modernization fit UAE regulatory requirements?
It has to be planned around them. Core migrations are elevated operational risk events under CBUAE supervision, and the FIT Programme’s instant payments and open finance initiatives keep the regulatory calendar active. Cutover windows should avoid examination cycles and capital transitions, and the programme should account for instant settlement and reporting obligations from the start rather than as a retrofit.
Planning a core banking modernization?
Kentro advises UAE and MENA banks on sidecar architecture, integration estate audits, and migration sequencing, working alongside your vendor selection rather than replacing it.
