Every core banking business case we have reviewed has the same shape. There is a licence cost, an integrator cost, an infrastructure cost, and a contingency of fifteen or twenty percent. The three numbers are researched carefully. The contingency is where the programme actually lives.
This is not an argument against replacing a core. It is an argument for costing the parts that are invisible on a vendor slide, because those are the parts that decide whether you finish.
Reconciliation is the project
A core migration is not a software installation. It is an assertion that two systems, given the same inputs, produce the same balances. Proving that assertion is most of the work, and it is almost never scoped as such.
The reconciliation surface is larger than it looks. It is not only balances. It is interest accrual at period boundaries, fee schedules that were amended by hand in 2011, back-dated corrections, accounts in states the new product model has no name for, and the several thousand accounts that exist because someone needed an exception and the old system let them have one.
- Every product variant that ever existed, not the ones currently sold
- Accrual and rounding behaviour at month, quarter and year boundaries
- Historic corrections, reversals and manual adjustments
- Accounts in states that the new data model cannot represent
Dual running is not a phase, it is a cost centre
Most plans include a period of dual running, and most plans budget it as a few months of extra infrastructure. In practice dual running means two systems, two operational teams, two sets of reports that have to agree, and a daily difference report that somebody senior reads every morning.
The infrastructure is the cheap part. The expensive part is that your best people are the ones who can explain a difference, and for the length of the dual run they are explaining differences instead of building anything.
The freeze you did not agree to
The moment a migration is announced, change to the old system becomes contentious. Every request now carries the question of whether it is worth doing twice. The answer is usually no, so it waits.
That queue is a real cost and it is never on the business case. If the programme runs eighteen months, the organisation has spent eighteen months not shipping things it would otherwise have shipped, and the backlog it inherits on day one is longer than the one it started with.
The mitigation is not to pretend the freeze will not happen. It is to decide, in advance and in writing, which categories of change are still allowed and who is permitted to approve them without reopening the debate each time.
Cutover is a rehearsal problem
Cutovers fail on the things that were never rehearsed end to end: the batch that runs at a different time on the last day of the month, the file a downstream system expects at a fixed path, the manual step that a specific person has always performed and never documented.
The only reliable defence is to rehearse the whole thing, on production-shaped data, more times than feels reasonable, and to treat every rehearsal failure as a finding rather than an embarrassment. A programme that has rehearsed cutover six times has a different risk profile from one that has rehearsed it twice, and the difference is not visible in any status report.
What to do with this
None of the above argues for keeping a core you have outgrown. Legacy cores impose their own compounding cost, and at some point the interest exceeds the principal.
It argues for costing the programme honestly, so the decision is made against a real number. A business case that includes reconciliation effort, a dual-running team, a change freeze and six rehearsals is a larger number and a far better decision than one that does not.
