Core Banking Migration – Programme Charter
This charter is written to show how a high-risk financial transformation can be framed with clarity: outcomes, guardrails, governance, and “stop” authority defined before delivery pressure peaks.
Important note
This document is an educational reconstruction based on public context. It is not an internal charter. Where assumptions are made, they are stated explicitly.
1) Programme purpose
| Purpose | Migrate customer accounts, transaction history, and servicing channels from a legacy core banking platform to a new platform, ensuring customer access, accuracy, payments continuity, and regulatory compliance. |
|---|---|
| Why it matters | In retail banking, service continuity is trust. A core migration is not “IT go-live” — it is a customer safety event requiring operational resilience. |
2) Scope
| In scope | Data migration (accounts/transactions), digital channels (online/mobile), branch servicing, payment rails/standing orders, monitoring and incident response, customer communications, stabilization support. |
|---|---|
| Out of scope | New product launches during cutover window; non-essential enhancements; broad process redesign beyond readiness needs. |
3) Non-negotiables (finance-grade)
- Customers can access funds and accounts reliably post-migration
- Balances and transaction history remain accurate and reconciled
- Payments (direct debits/standing orders/transfers) execute correctly
- Monitoring + incident response operate at “surge” capacity
- Regulatory obligations and audit trails are maintained
4) Success measures
| Day 1 indicators | Login success rate, payment success rate, incident severity count, reconciliation pass rate |
|---|---|
| Week 1 indicators | Complaint volume vs baseline, contact-centre wait times, backlog burn-down, error rates trending down |
| Stabilization exit | System stability sustained, customer impact normalized, operational load within baseline thresholds |
5) Delivery approach
| Method | Hybrid programme governance (stage gates + assurance) with iterative testing and rehearsals |
|---|---|
| Cutover strategy | Planned cutover with strict Go/No-Go criteria, war-room operations, and rollback plan rehearsals |
| Cadence | Weekly steering, daily cutover readiness standups in final phase, continuous risk review |
6) Governance & decision rights
| Steering Committee | Owns strategic decisions, risk appetite, and external stakeholder alignment |
|---|---|
| Go/No-Go Board | Approves cutover only when objective readiness evidence is met |
| Stop authority | Programme leadership can recommend No-Go without penalty when readiness gates are not met. (Assumption: Stop authority is defined in governance terms and expected to be respected.) |
| Audit trail | Decision log maintained for readiness sign-offs, exceptions, and risk acceptances |
7) Key assumptions (explicit)
- Programme deadlines may be influenced by separation/commercial constraints
- Status reporting can drift toward “milestones complete” unless rebalanced to “outcomes proven”
- Operational readiness (branches/contact centre) must be treated as a core deliverable
A banking cutover is not a project milestone. It is a controlled risk event.
← Back to Pack overview