And that core matters, because you didn’t buy the bank for its technology. You bought it for what it lets you do next; lending, deposits, payments, maybe cards, and possibly a loan book that’s already earning. That only pays off if those products and those accounts can move onto a stack built for them. 55% of banks name legacy core limitations as the single biggest barrier to their business goals, and a legacy core you've just acquired is no different. 

This is a guide to the part of the deal nobody puts in the pitch deck: getting the accounts you’ve bought off the legacy bank and onto your own digital entity, quickly, so the customers you paid for start paying you back. We’ve seen what happens when a digital native institution buys a legacy one. Here’s how it goes, and how to make it go fast. 

What happens when a digital native institution buys a legacy financial institution  

Maybe you’re a digital institution buying a licensed one. The point is vertical integration: adding lending, deposits and payments to what you already do, and picking up a licence, a customer base and possibly a performing loan book in the same deal. You already know the legacy core underneath isn’t coming with you. After all, nobody buys a bank for a core that isn’t even cloud-native. 

What it offers instead is cost and drag. Legacy cores consume 70 to 78% of a bank’s IT budget just to keep running, which leaves little for the product work the deal was meant to fund, and McKinsey puts operating costs for outdated cores at around ten times those of next-generation platforms. Legacy architecture also slows everything down, adding as much as 40% to time to market for new products. Which means any institution running a modern strategy on a batch-based, siloed, closed core spends its energy fighting the platform instead of building on it. 

This is why acquired banks so often stall in year one. The strategy is new and the core is old, and the core wins that argument every time until it is dealt with. The licence was the asset, but the inherited core is the liability, and getting your new accounts off it is the real work of the deal. 

When should the migration start? Before you sign  

The instinct is to close the deal, then work out what to do with the technology. That’s where year one goes. Don’t spend the first month asking whether the legacy core can be made to work. It can’t, not for what you’re planning. 

Before you sign is when the real planning happens: 

• Map what you’re buying: the accounts, the products, the data and where it lives 

• Decide what moves first and what can wait 

• Get your target stack ready to receive it 

This is the stage where we can come in and consult, so that by the time the ink is dry, you’ve got a migration plan and not a discovery project. 

As the deal closes, the migration starts. Begin the movement of accounts onto your entity, in waves, with the legacy bank kept running only for as long as there’s something left on it. 

In the first 90 days, the first accounts are live on your stack, your products are in front of them, and revenue from the customers you bought has started. The rest are moving behind them. 

Customers, staff and the regulator all still need continuity through this, and with this, they get it, but continuity comes from having planned the transfer before close, not from freezing the technology after it. 

Why data has to move first 

The single most common root cause of merger technology problems is data. Data harmonisation failures routinely persist in combined systems for years after integration is declared complete, and the reason is a sequencing mistake made early. Consolidating onto one system before the underlying data is clean simply runs the combined institution on duplicated, conflicted records, which is operationally and regulatorily worse than running two separate systems. 

The discipline is to harmonise the data first and consolidate the systems second. That means mapping every source, resolving the duplicates and gaps, and validating integrity before a single customer or account moves onto the new platform. It is unglamorous work and it is the difference between a migration that holds and one that produces reconciliation breaks for years.  

This is where a lot of acquisitions lose their first year. It’s important to map the legacy bank’s data to your stack, clean it, move accounts across in waves and reconcile as you go, so nothing lands on the wrong side of the ledger and the transfer is smooth for customers. We can help. 

Fastest way to revenue 

It’s tempting to do this as one big cutover: pick a weekend, move everything, switch the old bank off. But the problem is that a single cutover makes every account wait for the last account to be ready, and nothing earns until all of it does. 

Moving in waves is the fastest route to revenue. That way, the first accounts are live on your stack, using your products and generating revenue, while the rest are still in transit. You learn from the first wave and the second goes quicker. European Banking Association case studies record a phased migration that saved 38% in 18 months and delivered 62% faster time to market for new products, and Accenture research finds modernisation reducing total cost of ownership by 38 to 52% while enabling the innovation capability that legacy systems block.  

What does the core you move onto decide? 

The core you select is a vital asset the institution gets rebuilt on, and its properties set the ceiling on everything the acquired bank can become. Modernising onto another closed, batch-based platform trades one constraint for a newer one. Any core worth moving onto is API-first, real-time, and built for governed data access, so the acquired institution can finally process in real time, integrate with the wallets and gateways its customers use, configure its own products, and run AI on a data foundation it can reach.There is a governance dividend in getting this right and it matters more for a foreign-controlled entity held to a visible standard by the regulator.  

Oradian is built for this. As an AI-native, API-first core banking platform for banks and lenders in emerging markets, it’s the stack acquirers move their newly bought accounts onto: real-time processing, open integration and governed data access, with the migration run in waves so revenue starts before the last account has landed. We can consult before the deal, so the plan exists on day one, or start the work as it concludes. And because implementation is delivered by in-market teams in Makati, Lagos and Zagreb, the people doing it know the regulator, the payment rails and the market you’ve just bought into. 

The licence was the hard part to acquire.  

Getting the accounts off the old core and earning on yours is the hard part to do fast, and it’s where the value of the deal is won or lost.

Move them in the right order, onto infrastructure built for what the institution is trying to become, and the bank you bought turns into the bank you set out to build. 

Buying a bank? Talk to us before you sign 

The fastest transitions are planned before the deal closes. If you’re evaluating an acquisition, or in the middle of one, talk to us now about moving the accounts across quickly and getting to revenue from them early. Contact vanda.jirasek@oradian.com to learn how Oradian can help.