Modernisation engineering for banking applications, starting from what the system is actually connected to rather than from what the documentation says it is.
The application itself is rarely the hard part. A twenty or thirty-year-old banking application does a reasonably well-understood job, and the people who run it know how it behaves.
Every modernisation programme produces a dependency diagram. Every modernisation programme then discovers a consumer that was not on it. The places they hide are consistent and most of them are discoverable without asking anybody.
The dependency map is from documentation
Which describes the system as designed, not as connected.
Technical debt is measured by age
So stable old systems outrank unstable newer ones.
Nobody will agree an application is unused
So it gets modernised instead of switched off.
The strangler has no end date
And the institution now runs both systems indefinitely.
Rollback covers code and not data
Which makes it unusable once the new system has written.
The knowledge is in two people
And at least one of them is close to retirement.
Vendor systems cannot be changed at all
Which is a boundary condition, not a scope decision.
Validation is testing rather than comparison
When the only real proof is running both and reconciling.
Ask what connects directly to the database of the application you intend to modernise. Not what the interfaces are, what connects to the data. Pull the connection logs for a month and attribute every source. The list is almost always longer than the documented one, it usually contains at least one consumer nobody present can explain, and it frequently contains a reporting tool or a spreadsheet belonging to a team that was never part of the programme. That exercise takes days and it changes the scope.
Modernisation programmes are frequently scoped as a target architecture applied to an inventory. That skips the cheapest decision available, which is deciding what not to carry forward.
Most banking estates contain applications that are barely used, duplicated by something newer, or serving a process that stopped years ago. They are modernised rather than retired because retiring one requires somebody to state that nothing depends on it, and after the discovery work in section 2 nobody is willing to say that casually.
Step 1
Inventory the portfolio with the business function each application serves
Step 2
Discover real dependencies from traffic, over a full cycle
Step 3
Measure what each application actually costs to keep
Step 4
Triage each one: retain, retire, rehost, replatform, refactor or replace
Step 5
Sequence by risk and dependency rather than by enthusiasm
Step 6
Define the target architecture for what survives triage
Step 7
Design the migration with parallel running where it is possible
Step 8
Capture the current behaviour as tests before changing anything
Step 9
Design rollback including data, and test it
Step 10
Build the anti-corruption layer around what cannot change
Step 11
Execute in phases that each stand alone
Step 12
Validate by comparison rather than by test, and reconcile
Step 13
Decommission on an agreed date with a named owner
Ask which applications in your portfolio could simply be switched off. Then ask what evidence would be needed to be confident. In most estates a meaningful number of applications are serving almost nobody, and the blocker is not technical but the absence of anybody willing to assert that nothing depends on them. The dependency discovery in section 2 is what turns that from an assertion into evidence, and retirement is the cheapest modernisation outcome available by a wide margin.
Grouped by what each part does. The first group decides whether the rest is aimed at the right applications, and it is the group most often compressed into a two-week exercise.
Assessment and planning
Application portfolio assessment by business function, cost, risk and dependency rather than by technology stack
Dependency discovery from observed traffic over a full business cycle, as described in section 2
Technical debt measurement on the indicators described in section 3, which produces a different ranking to age
Modernisation triage including retirement, with the evidence required for each decision
Sequencing and roadmap built on dependency and risk, with a decommission date per application
Migration patterns
Rehosting where the application is fine and the platform is not, which is the cheapest useful move and is frequently dismissed too quickly
Replatforming where the runtime, database or middleware is the constraint
Refactoring where the code will live for another decade and currently cannot be changed safely
Replacement where a package or an existing platform does the job and the custom application has no remaining advantage
API enablement and anti-corruption layers around systems that cannot be changed at all
Incremental migration with parallel running, and an honest statement where parallel running is not possible
Platform and architecture
Hybrid and cloud architecture chosen on your residency, resilience and cost position rather than as a direction of travel
Containerisation and orchestration where the workload benefits, and left alone where it does not
Event-driven and API-based integration replacing point-to-point connections, which is where most of the estate’s fragility lives
Database modernisation, including the cases where the data model is the actual legacy rather than the code
User interface modernisation, which is frequently the visible part of a programme whose value is elsewhere
Delivery and operations
Continuous integration and deployment pipelines, with change control proportionate to the system’s risk
Secure development practices integrated into the pipeline rather than applied as a gate
Observability built in during migration, since a system nobody can see is a system nobody can cut over confidently
Automated testing, including the comparison harness that parallel running depends on
Knowledge capture, because the two people who understand the current system are a risk the programme should reduce rather than rely on
The third column is the point of the table. These classes of application fail differently during modernisation, which is why the sequencing and the validation approach should differ between them.
| Application class | Why it needs modernising | What makes it risky to touch |
|---|---|---|
| Core-adjacent applications | They constrain everything around them | Everything depends on them, often invisibly |
| Loan processing systems | Policy is hard-coded, change is slow | In-flight cases during any cutover |
| Payment applications | Fragile integrations, poor state handling | A defect here is a financial loss |
| Internal operations platforms | High maintenance, low visibility | The institution runs on them unnoticed |
| Customer servicing systems | Dated experience, slow to change | Live customer interactions at cutover |
| Reporting applications | Undocumented logic, fragile queries | The annual extract nobody tested |
A test suite proves that the new implementation does what somebody expected. It cannot prove that it does what the old system did, and in a banking context that is the question being asked.
The only real validation is to run both against the same inputs and compare the outputs, every difference explained rather than tolerated. That is more work than testing and it is the difference between a cutover with evidence and a cutover with confidence.
A comparison harness running both implementations against production inputs, with differences categorised rather than counted
Characterisation tests written against the current system before it is touched, which capture what it actually does rather than what it was specified to do, including the behaviours nobody intended and consumers have come to rely on
An anti-corruption layer around anything that cannot change, with a stated boundary on what logic it may hold
API and event-based integration replacing point-to-point connections, which is where the estate’s fragility concentrates
Containerisation and orchestration where the workload benefits from it, chosen on the workload rather than as a standard
Integration middleware or a service layer, modernised rather than preserved, since this is frequently the oldest part of the estate
Continuous delivery with change control proportionate to each system’s risk, so a reporting change and a payments change are not the same process
Observability built during migration rather than after it, because a system you cannot see is a system you cannot cut over confidently
And data integration on the patterns described on our Banking Data Platform Engineering page, where the migration reconciliation discipline is argued in full
Ask when your rollback plan was last executed rather than reviewed. Reviewed is a document check. Executed means somebody ran it, with data written after cutover, and measured how long it took and what was left inconsistent. If the answer is never, then the programme is relying on a plan nobody has proven, and the first time it is used will be under maximum pressure with an audience. Rehearsing it is cheap, it almost always finds something, and it is the single most effective risk reduction available before a banking cutover.
Which regulatory, operational resilience, change management, outsourcing and data protection requirements apply to a given migration, and what approval or notification is required, are determined by your compliance, risk, audit and legal functions, based on your operating markets. We do not interpret those requirements and this page does not state which apply to you.
Technology supports a control framework. It does not independently establish one, and no migration approach makes a change compliant.
Migration risk and control
- A risk assessment per migration rather than per programme, since the risk of a reporting application and a payment application are not comparable
- Data integrity evidenced by comparison and reconciliation rather than asserted by testing, as described in section 6
- Rollback designed to include data, exercised in rehearsal, with a decision point and an owner
- Dependency discovery re-run before decommissioning, because consumers are added while a programme is in flight
Security and access
- Secure development practices in the pipeline, with the modernised system held to current standards rather than to the ones its predecessor was built under
- Access and entitlement re-established deliberately in the target, since lifting legacy permissions across is how excessive access is inherited
- Secrets, credentials and interface certificates inventoried during migration, as these are a common and avoidable cause of post-cutover incidents
- Data handled under its existing classification throughout the migration, including in non-production environments, which is the exposure described on our Banking Data Platform Engineering page
Continuity and resilience
- Business continuity maintained through the migration, with the continuity position for the transition period explicitly stated
- Recovery objectives for the target agreed with the business rather than inherited from the legacy system’s actual behaviour
- In-flight work treatment agreed with the business in advance, as described in section 5
- Resilience testing on the target before cutover rather than after, including the failure paths
Change and evidence
- Change management proportionate to the system, with the approvals your framework requires and the evidence retained
- An audit trail of the migration itself: what moved, when, with what validation result and whose approval
- Documentation produced during the work rather than afterwards, since the knowledge is accurate while the work is happening
- Decommissioning evidenced, including the final dependency check and the retention of anything required from the retired system
Modernisation programmes report migration progress, which measures the programme rather than the outcome. The reason for modernising was that the estate was expensive to run and slow to change, so those are the measures that establish whether it worked.
| Failure | How it presents |
|---|---|
| Both systems still running | Migration complete, nothing decommissioned |
| Cost went up | Dual running normalised into the budget |
| A consumer was missed | Something fails weeks or months later |
| The annual extract did not run | Discovered by whoever needed to submit it |
| Change lead time unchanged | New technology, same approval chain |
| Deployment frequency up, failures up | Speed without the control to support it |
| Legacy permissions were carried across | Excessive access inherited by the target |
| Post-migration defects on a cycle | Stable daily, broken at period end |
The outcomes below follow from three choices: prove dependencies from traffic, triage with retirement as a real option, and agree the decommission date before the migration starts.
Change lead time reduced, measured from business request to live rather than from development start
Maintainability improved where it was costing something, with the technical debt indicators re-measured rather than assumed
Integration simplified through API and event patterns replacing point-to-point connections
Resilience improved against objectives agreed for the target rather than inherited from the legacy behaviour
Legacy constraints removed, including those around systems that cannot change, through anti-corruption layers
A smaller estate, because retirement was treated as an outcome rather than as a failure to modernise
Dual running ended, on the dates agreed at the start, with the decommissioning evidenced
We will take one application and establish four things: what actually depends on it from its own traffic, what it costs to keep as it is, whether retirement is realistic, and what a defensible migration and rollback would require. You get the findings whether or not we build anything.
CaliberFocus starts banking modernisation by proving what depends on each system from its actual traffic, because the dependency nobody documented is the one that stops a programme. We triage with retirement as a real option, validate by running both systems and reconciling, design rollback to include data, and agree a decommission date with a named owner.
- Dependency discovery from observed traffic over a full business cycle
- Portfolio triage that treats retirement as a genuine outcome
- Parallel running and reconciliation rather than testing alone
- A decommission date and owner agreed before migration starts
Security & Compliance
