A core banking migration should not be treated as a software replacement.
It is a controlled transfer of banking responsibility.
The old system may currently maintain customer accounts, balances, product rules, interest calculations, transaction histories, limits, fees and interfaces to dozens of surrounding applications.
Replacing the technology therefore means transferring responsibility for processes that the bank must continue performing every day.
Customers still need access to their accounts.
Payments still need to clear.
Branches still need to operate.
Transactions still need to reconcile.
Finance still needs an accurate general ledger.
Regulatory and management reports still need to be produced.
That is why the safest migration is rarely:
Old core → switch off → new core.
A more resilient approach is:
Understand → isolate → connect → migrate → reconcile → prove → retire.
The bank moves functions deliberately while keeping a clear system of record at every stage.
For African banks, this matters increasingly as the financial infrastructure around the core becomes more connected. Nigeria's Payments System Vision 2028 places interoperability, security, innovation and regional integration at the centre of its current payments strategy. South Africa is simultaneously modernizing national payment infrastructure through its Payments Ecosystem Modernisation Programme. Kenya's banking sector is increasingly dependent on third-party technology providers and connected digital services, while Ghana has strengthened its cyber and information-security framework for regulated financial institutions.
A bank migrating its core therefore has to protect more than the core itself.
It has to protect the ecosystem connected to it.
Why banks eventually outgrow legacy core systems
A legacy core is not necessarily a bad system.
Many older platforms remain dependable precisely because they have processed years of real transactions, accumulated product rules and survived countless operational scenarios.
The problem appears when the system becomes increasingly difficult to change around.
Typical symptoms include:
- New products taking too long to launch
- Limited API capabilities
- Heavy reliance on batch processing
- Multiple manual integrations
- Increasing dependence on a small group of specialists
- Expensive changes to existing product rules
- Duplicate customer or transaction data
- Difficult reporting
- Separate operational databases
- Manual reconciliation between connected systems
- Customer channels constrained by core limitations
- Increasing effort required to satisfy new technology requirements
The case for modernization should therefore not be:
The system is old.
It should be:
The current architecture is preventing the bank from delivering an important business or operational outcome at an acceptable level of cost, speed or risk.
That distinction matters.
A bank should not undertake one of its most complex technology programmes simply because a newer platform exists.
Core banking migration is a business architecture decision
Before choosing a replacement platform, the bank should determine exactly what the current core does.
That sounds obvious.
In established institutions, it often is not.
Over time, responsibilities that logically appear to belong to the core may have moved elsewhere.
A customer profile may originate in one platform.
Account information may sit in the core.
Limits may be controlled in another application.
Charges may be calculated through a separate engine.
Payments may pass through middleware.
Reconciliation may happen in another system.
Finance may depend on interfaces into the general ledger.
Operations teams may use spreadsheets or internal applications to resolve exceptions created between them.
The first migration challenge is therefore not moving data.
It is discovering where banking responsibility currently lives.
The Flex Seven-Gate Core Migration Framework
A phased migration can be structured around seven gates:
Map → Isolate → Prepare → Prove → Migrate → Stabilize → Retire
Each gate answers a different question.
The bank should not move to the next gate simply because development has finished.
It should move when the required operational evidence exists.
Gate 1: Map the real banking estate
Start with a dependency map.
The bank needs to know what relies on the core before it can safely change the core.
Map:
Products
- Current accounts
- Savings
- Deposits
- Loans
- Overdrafts
- Corporate accounts
- Fees
- Interest
- Limits
- Standing instructions
Channels
- Mobile banking
- Internet banking
- USSD
- Branch systems
- ATMs
- Agency banking
- Corporate banking portals
- APIs
- Contact centre tools
Financial infrastructure
- Domestic payment switches
- Card processors
- RTGS connections
- ACH or clearing
- Mobile-money providers
- International payments
- Treasury
- Settlement
Internal systems
- CRM
- General ledger
- Finance
- Risk
- AML and transaction monitoring
- Customer onboarding
- Data warehouse
- Regulatory reporting
- Document management
- Collections
- Credit systems
Operational workflows
- Failed transaction handling
- Reversals
- Account restrictions
- Dormant-account processes
- Fee corrections
- Interest adjustments
- Customer disputes
- End-of-day processing
- Reconciliation
- Manual postings
For every dependency, answer:
- What data enters the core?
- What data leaves it?
- In what format?
- How often?
- Which system is authoritative?
- What happens if the interface fails?
- Who owns the exception?
- How is the result reconciled?
This becomes the migration dependency register.
Without it, the bank can successfully migrate the database and still break the business.
Map critical operations before changing technology
The Basel Committee's operational-resilience principles focus on a bank's ability to deliver critical operations through disruption and recognise technology failures and third-party dependencies as important sources of operational risk.
For a core migration, that means the programme should identify the services that cannot tolerate an uncontrolled interruption.
For example:
- Account access
- Deposits and withdrawals
- Payment initiation
- Settlement
- Balance enquiry
- Card authorisation
- Customer servicing
- Regulatory reporting
The migration programme should then work backwards from the continuity requirements of those services.
Gate 2: Isolate what actually needs replacing
One of the most expensive mistakes in core modernization is expanding the definition of "core".
The existing platform may be weak in some areas and perfectly adequate in others.
Before beginning a full replacement, classify each capability:
This prevents the programme from becoming a simultaneous replacement of:
- Core banking
- CRM
- Internet banking
- Mobile applications
- Payments
- Data warehouse
- General ledger
- Reconciliation
- Customer support tools
unless there is a genuine reason to change all of them.
A core migration is already complex.
Do not increase the blast radius unnecessarily.
Separate the core from the experience around it
Some problems blamed on the core are actually channel or workflow problems.
If corporate customers cannot see payment status, the bank may need a better corporate portal.
If operations teams cannot investigate transactions, the problem may be the operations console.
If new partners cannot connect easily, an API or orchestration layer may solve the immediate problem.
If reconciliation requires several spreadsheets, the missing system may be a reconciliation platform.
This does not eliminate the eventual case for core replacement.
It helps the bank distinguish between:
We need a new core
and
We need better capabilities around the core.
That distinction can change the migration strategy considerably.
Gate 3: Prepare the new architecture before moving customers
The new core should not become the centre of another tightly coupled architecture.
Before migration begins, define how surrounding systems will communicate with it.
Where appropriate, introduce an integration layer that separates channels and operational systems from core-specific interfaces.
Instead of:
Mobile app → legacy core
Corporate portal → legacy core
Branch system → legacy core
Payment system → legacy core
the architecture may evolve towards:
Channels and systems → integration/orchestration layer → core services
The purpose is not to add middleware for its own sake.
It is to reduce the number of applications that have to understand the internal structure of the core.
That makes later migration phases easier because upstream systems can continue calling stable interfaces while the implementation underneath changes.
Build an interface inventory
Every interface should have:
- Owner
- Source system
- Destination
- Data fields
- Frequency
- Authentication method
- Error handling
- Retry rules
- Monitoring
- Reconciliation process
- Expected volume
- Availability requirement
This sounds administrative.
During migration, it becomes one of the most important control documents in the programme.
Treat data migration as a separate workstream
Moving data is not the same as copying tables.
The bank must decide how information in the old system maps to the new one.
Examples include:
- Customer IDs
- Account numbers
- Product codes
- Account statuses
- Interest rules
- Fee structures
- Currency
- Limits
- Beneficiaries
- Mandates
- Historical transactions
- Loans
- Collateral references
- Accrued interest
- Dormancy status
Some legacy data will be incomplete.
Some will be duplicated.
Some will contain values that were valid under historical product rules but are not represented in the new platform.
Some may exist primarily because an older application needed it.
Migration therefore requires three different questions:
What must move?
What must remain accessible?
What should not be carried into the new core?
Those answers should be agreed before large-scale conversion begins.
Gate 4: Prove the new core without giving it full control
A bank should avoid making the first meaningful test of a new core the day customers are moved onto it.
The new environment should be exercised using production-like data, workflows and transaction volumes.
Testing should include more than normal transactions.
Test:
- Account opening
- Interest calculation
- Fee application
- Transaction posting
- Reversals
- Failed payments
- Partial failures
- Duplicate requests
- End-of-day processing
- End-of-month processing
- Limits
- Holds
- Dormancy
- Account closure
- Batch jobs
- Reconciliation
- General-ledger postings
The system also needs to be tested when dependencies fail.
What happens when:
- The payment switch is unavailable?
- An API times out?
- A transaction is submitted twice?
- The new core posts but the channel does not receive confirmation?
- The general-ledger interface fails?
- The new platform restarts during processing?
A core platform must handle imperfect conditions predictably.
Use shadow processing where practical
For selected workloads, the bank can allow the new platform to calculate or reproduce an outcome without becoming the authoritative posting system.
The old core remains authoritative.
The new system receives equivalent inputs.
Teams then compare outputs.
For example:
- Balances
- Interest
- Fees
- Product rules
- Account states
- Posting results
- End-of-day totals
Differences can then be understood before customer responsibility moves.
The objective is not permanent duplication.
It is evidence.
Reconciliation should be a migration control, not an accounting afterthought
Every migration phase should define what has to reconcile before progression.
Possible controls include:
Customer count
Old system = new system
Account count by status
Old system = new system
Balances by currency and product
Old system = new system
General-ledger totals
Subledger totals = control accounts
Accrued interest
Expected amount = migrated amount
Transactions migrated
Source count = destination count
Exceptions
Every difference has an owner and resolution
A technically successful migration with unexplained financial differences is not a successful migration.
Gate 5: Migrate in controlled units
The safest migration unit depends on the bank's architecture.
It may be:
- Product
- Customer cohort
- Branch
- Legal entity
- Country
- Account type
- New customers versus existing customers
There is no universally correct sequence.
The governing principle is:
Choose a migration unit that can be clearly identified, reconciled, supported and rolled back or contained if necessary.
One useful strategy: new business first
Where the architecture allows it, a bank may introduce the new core first for:
- A new product
- New-to-bank customers
- A new subsidiary
- A new digital proposition
Existing customers remain on the old platform.
This allows the new core to prove itself under real conditions without immediately carrying the entire bank.
The challenge is that the institution temporarily operates two cores.
That means the architecture must handle:
- Customer identity across both systems
- Reporting
- Payments
- Product servicing
- Cross-core transfers
- Operations
- General-ledger consolidation
Dual-core operation is therefore a transition model, not an end state.
Another strategy: product migration
The bank may migrate a simpler product family first.
For example:
Phase 1: Savings
Phase 2: Current accounts
Phase 3: Deposits
Phase 4: More complicated lending or corporate products
The actual order depends on each institution.
A seemingly simple product can have complex integrations, so migration order should come from dependency analysis rather than assumptions.
Do not split ownership ambiguously
The most dangerous situation is when both cores appear capable of changing the same account.
During each phase, the bank should be able to answer:
Which system is authorised to post to this account?
That answer should be deterministic.
The old and new cores can exchange information.
They should not compete for authority.
Gate 6: Stabilize each migration wave before expanding it
The completion of a data conversion does not mean the wave is finished.
The migrated population needs to survive normal banking operations.
Monitor:
- Posting success
- Reconciliation differences
- Failed integrations
- Customer complaints
- Manual interventions
- Batch processing
- End-of-day completion
- End-of-month processing
- Response times
- Operational queues
- Incident volumes
Define a stabilization period and exit criteria before the next cohort is added.
For example:
- No unresolved critical defects
- Financial reconciliation completed
- All high-priority interfaces stable
- End-of-day completed within tolerance
- Support queues within agreed range
- Operational teams trained
- Incident response tested
This keeps programme momentum tied to operating evidence instead of the project calendar.
Gate 7: Retire the legacy core deliberately
Migration is not complete when the last active account leaves the old core.
The bank still needs to deal with:
- Historical records
- Regulatory retention
- Audit access
- Old statements
- Closed accounts
- Disputes
- Data lineage
- Infrastructure
- Software licences
- Vendor contracts
- Specialist access
- Archived interfaces
A bank that keeps the legacy platform running indefinitely "just in case" may preserve much of the cost and complexity the migration was intended to remove.
The programme needs a retirement plan.
Separate archive access from operational access
Historical information may need to remain available without keeping the entire transactional system alive.
Depending on requirements, the bank may move historical records into:
- A controlled archive
- Data warehouse
- Read-only repository
- Regulatory retention platform
The objective is to preserve evidence without preserving unnecessary operational dependency.
Define a point of no return
Eventually:
- New transactions stop reaching the legacy core.
- Legacy interfaces are disabled.
- Operational users lose write access.
- The old environment becomes read-only.
- Historical access moves to the agreed archive.
- Infrastructure is decommissioned.
Until those steps happen, the organisation is still partly operating the old architecture.
Why a big-bang migration sometimes fails
A big-bang cutover is attractive because it appears to shorten the transition period.
Everyone moves at once.
The old system stops.
The new one begins.
There are situations where this may be necessary.
But it concentrates risk.
A defect in:
- Data conversion
- Product configuration
- Batch processing
- Integration
- Authentication
- Payment processing
- Interest
- General-ledger posting
can affect the entire migrated population simultaneously.
A phased model limits the scope of each migration event and creates opportunities to learn.
The trade-off is that it requires stronger transitional architecture.
The bank may need to operate:
- Two data environments
- Temporary synchronization
- Additional reconciliations
- More complex reporting
- Transition interfaces
Phased migration is therefore not automatically easier.
It is easier to contain.
Core migration in Nigeria
Nigeria's current Payments System Vision 2028 was launched in June 2026 and is built around interoperability, security, inclusion, innovation, trust and collaboration. The CBN also identifies cross-border integration and alignment with international standards as priorities.
For a Nigerian bank, core migration should therefore map every connection between the core and:
- Domestic payment infrastructure
- Switching
- Card processing
- Mobile and web banking
- Open-banking interfaces
- Corporate banking
- Agent channels
- Settlement
- Reconciliation
The migration question is not simply whether balances move correctly.
It is whether the migrated core continues participating correctly in Nigeria's broader financial infrastructure.
A practical Nigerian migration strategy may therefore preserve existing payment connectivity initially while moving account and product responsibilities in controlled phases.
Core migration in South Africa
South Africa is actively modernizing its national payments ecosystem. SARB's Payments Ecosystem Modernisation Programme aims to support faster, simpler, inclusive and secure digital payments and includes infrastructure modernization and wider interoperability.
For South African banks, the migration programme should give particular attention to:
- Operational resilience
- Architecture governance
- Security
- Data governance
- Third-party dependencies
- Payment connectivity
- Business continuity
- Exit planning
The broader lesson from modernizing critical financial infrastructure applies inside the bank as well: new technology needs to be introduced without weakening the reliability of the service customers already depend on.
Core migration in Kenya
Kenyan banks operate in a highly connected technology environment.
The Central Bank of Kenya's 2025 survey of third-party technology service providers examined banks' dependence on external technology, including services supporting important digital banking capabilities.
Its 2025 Banking Sector Innovation Survey also reflects continued innovation across Kenya's commercial banking sector.
For a Kenyan core migration, the dependency map should therefore include not only internal applications but every significant:
- API
- Cloud provider
- Digital channel
- Payment provider
- Identity service
- Data provider
- Technology partner
A new core can be technically modern while remaining operationally fragile if nobody owns the dependencies around it.
Core migration in Ghana
Ghana is also modernizing its payments environment. The Bank of Ghana's National Payment Systems Strategy for 2025–2029 is intended to support a secure, inclusive and innovative payment ecosystem.
The Bank of Ghana also issued a revised Cyber and Information Security Directive in March 2026, strengthening the regulatory environment around cyber and information-security risk for regulated institutions.
For Ghanaian banks, core modernization should therefore build security, continuity and third-party governance into the migration programme rather than treating them as final compliance reviews.
The migration team is larger than IT
Core migration requires a cross-functional operating team.
It should typically involve:
Technology
Owns architecture, environments, interfaces, infrastructure and technical delivery.
Banking operations
Explains what actually happens when normal transactions fail.
Product
Owns product definitions, rules, pricing and customer outcomes.
Finance
Owns accounting treatment, general-ledger reconciliation and financial control.
Risk and compliance
Ensures the new process supports the institution's regulatory and control requirements.
Information security
Owns security architecture, access, testing and incident requirements.
Customer service
Identifies customer-impact scenarios and support requirements.
Internal audit
Can help ensure that migration controls, evidence and governance are designed appropriately.
Executive sponsor
Resolves decisions that cross departmental boundaries.
Core migration fails organisationally when it becomes "the technology team's project".
The technology team can migrate the platform.
It cannot independently define how the bank should operate.
The questions every migration programme should answer
Before moving the first live account, the programme should be able to answer:
- Which system is authoritative for every migrated account?
- How do we know the converted balances are correct?
- How do we know product rules behave correctly?
- What happens when an integration fails?
- Can payments continue if one dependency is unavailable?
- How will we reconcile the first day?
- How will we reconcile the first month-end?
- What happens to transactions already in progress at cutover?
- How will customer service identify which system contains an account?
- What is the rollback or containment plan?
- Which conditions stop the next migration wave?
- Who has authority to declare the wave stable?
- How will historical data remain available?
- When can the old platform actually be switched off?
If several of those answers remain unclear, the programme is not ready for cutover.
Where Flex Enterprise Solutions fits
A core migration does not always require the same partner to replace every component.
There is significant work around the core itself:
- Workflow mapping
- Integration architecture
- Operational dashboards
- Reconciliation
- Exception management
- Customer and partner portals
- Approval workflows
- Data movement
- Legacy interfaces
- Transition systems
Flex Enterprise Solutions builds financial software for banks around payments, approvals, reconciliation, reporting, operational dashboards, portals, integrations and legacy-system modernization. Flex's published delivery approach begins with discovery and workflow mapping before solution design, build and integration.
This gives Flex a useful role in core modernization programmes:
Helping the bank build and connect the operational layer around the migration.
That may mean:
- Decoupling a customer portal from a legacy core
- Building APIs around an older system
- Creating reconciliation controls for migration waves
- Building an operations console that works across old and new systems
- Modernizing a workflow before the underlying core changes
- Connecting the replacement platform to existing banking and finance systems
- Building a transition layer that can later be retired
The objective is not to replace working infrastructure simply to enlarge the project.
It is to reduce migration risk by changing the right layer at the right time.
The best migration is one the bank can explain
A core modernization programme should not require executives to accept a simple instruction:
Trust us. The migration worked.
The bank should be able to demonstrate why it worked.
For every migration wave:
- The correct customers moved.
- The correct products moved.
- Balances reconciled.
- Product rules produced expected outcomes.
- Connected systems continued operating.
- Exceptions were understood.
- Financial records reconciled.
- Operations could support the migrated population.
- The previous system stopped controlling the migrated accounts.
That is what turns migration from a technology event into a controlled transfer of banking responsibility.
The goal is not to reach the new core as quickly as possible.
It is to reach it without losing the operational knowledge, financial integrity and customer confidence the old core spent years supporting.
Frequently Asked Questions
What is a core banking system migration?
A core banking system migration is the transfer of banking products, customer and account data, transaction processing and related operational responsibilities from an existing core platform to a new environment. It usually also requires changes to surrounding channels, integrations, reporting and operating processes.
Should a bank replace its legacy core banking system all at once?
Not necessarily. A big bang migration can shorten the period in which two environments coexist, but it also concentrates migration risk. Where the architecture permits, a phased migration by product, customer cohort, business unit or another clearly controlled boundary can make problems easier to contain.
What is the safest way to migrate a core banking system?
There is no universally safest sequence. A strong migration begins with dependency mapping, data preparation, clear system-of-record rules, realistic testing, financial reconciliation, staged cutovers, operational stabilization and a defined retirement plan for the old environment.
Can a bank modernize without immediately replacing its core?
Yes. A bank can sometimes improve customer portals, integrations, approval processes, reconciliation, reporting and operational workflows while retaining the existing core. This can solve immediate problems and also prepare surrounding systems for an eventual migration.
What data should move to a new core banking system?
The answer depends on the new platform and the bank's legal, operational and reporting requirements. Active customer, account, product and balance data will normally be important, but not every historical field needs to become active data in the new core. Historical information may sometimes be preserved in a controlled archive instead.
How do banks validate balances during core migration?
Banks should define reconciliation controls before migration. These may compare customer counts, account counts, balances, accrued interest, transaction totals, product totals and general-ledger control accounts between the old environment, migration files and new core.
Should old and new core banking systems run in parallel?
They may coexist during a phased programme, but authority must remain clear. The institution should know which core is allowed to post to each account. Long-term ambiguous dual processing creates significant operational and reconciliation complexity.
What are the biggest risks in a core banking migration?
Major risks include incomplete dependency mapping, poor data quality, incorrect product configuration, failed integrations, unclear system ownership, unreconciled balances, inadequate exception testing, insufficient operational readiness and premature decommissioning.
How should African banks approach core banking modernization?
Banks in Nigeria, South Africa, Kenya and Ghana should design migration around their local payment infrastructure, regulatory requirements, technology-provider dependencies and existing architecture. The same core platform may require a different integration and migration strategy in each market.
Can Flex help with a legacy core banking migration?
Flex Enterprise Solutions can support the software and workflow layers surrounding a modernization programme, including integrations, reconciliation tools, operational dashboards, portals, approval workflows and legacy-system modernization. The exact scope depends on the bank's existing architecture and migration programme.
How long does a core banking migration take?
There is no credible universal timeline. Duration depends on the size of the bank, products, data quality, integration estate, migration approach, regulatory requirements, testing requirements and how much surrounding technology is being changed at the same time.
%20(3).png)
.png){kind=small}