Replacing a core is the largest discretionary risk most banks ever take, and the ritual around it is well established: a strategy paper, a longlist, a beauty parade, a recommendation to the board. The board engages hardest at the vendor decision, because that is the decision put in front of it.
But the vendor is rarely why these programmes succeed or fail. The determining decisions come earlier, attract less scrutiny, and are often made implicitly — by a planning assumption nobody re-examines, or by whoever wrote the first version of the business case. Ten of them deserve the board's attention before a shortlist exists.
The ten
- Whether to replace at all. The case for not replacing — remediate, wrap, buy time — deserves an author who is rewarded if it wins. A business case written by the team that wants the programme is an advocacy document, and boards should read it as one.
- What the bank will stop doing. Every core carries decades of product variants, rate exceptions and bespoke arrangements. Deciding which of these do not survive the migration is an executive decision about customers and revenue. Left to the programme, it will be deferred; deferred, it becomes the single largest source of cost and delay.
- Whether this is a replacement or a transformation. Like-for-like replatforming and redesigning the bank are different undertakings with different risk profiles. Most programmes claim the first and attempt the second. Choosing openly — and pricing the choice — is harder and considerably cheaper.
- Who owns the outcome, and whether they will be there at cutover. These programmes outlast the average executive tenure. An owner who expects to have moved on before go-live has, whatever the governance chart says, a different risk appetite from the institution.
- What "done" means. If success is defined as go-live, the programme will optimise for go-live — and the decommissioning, the data clean-up and the benefits will remain outstanding indefinitely. The definition of done, and who certifies it, is a pre-vendor decision.
- How the customer data moves. Big bang, phased by product, or migrate-on-renewal is a risk decision dressed as a technical one. It determines the shape of the programme, the duration of dual running, and what a bad weekend can cost. It belongs to the board's risk appetite, not the solution architecture.
- The contingency the board will actually tolerate. Every plan contains a rollback provision; few boards have discussed what invoking it would mean, or where the point of no return sits. A board that first considers this at cutover rehearsal has considered it too late.
- What the regulator sees, and when. Supervisors are rarely surprised well. Deciding early what will be shared, how independent the assurance over it is, and what evidence a licence-holder must be able to produce shapes the programme far more cheaply than repairing a supervisory relationship later.
- How the vendor's incentives are constructed. The negotiating leverage is greatest before selection and never recovers. The contract questions that matter — who carries migration risk, what happens when the roadmap and the bank's needs diverge, the cost of leaving — are settled in the structure of the process, not in the final round of negotiation.
- What happens to the old core. Business cases assume decommissioning; balance sheets accumulate systems that were never switched off. If the funding and accountability for turning the old estate off are not committed at the start, the savings line in the business case is a hope, not a plan.
The pattern
None of these ten is technical, and none can be delegated to a vendor or a systems integrator, however capable. They are decisions about what the bank is willing to stop, to risk, and to be held accountable for — which is why they belong to the chief executive and the board, and why they are worth settling while the bank still holds all of its leverage: before the vendor is chosen.