Moving banking applications, databases and workloads between environments with reconciliation as the deliverable, a cutover that has been rehearsed, and a rollback decision that has a clock time on it.
Migrations rarely fail loudly. They report success, and then a difference surfaces weeks later: a segment of records that never arrived, an amount that rounds differently, a name with a character replaced, a date that moved by a day at a period boundary.
Each of these is commonly found in production after a migration that passed its checks. What detects each one is specific, and only one of the six is caught by comparing record counts.
| The Difference | Where It Comes From | What Detects It |
|---|---|---|
| Missing Records | A filter, a failed batch, rejected rows | Counts per table and per segment. |
| Value Drift | Rounding, precision, type conversion | Value totals, which counts will not show. |
| Encoding Damage | Character set differences in text | Field comparison on names and addresses. |
| Date and Time Shifts | Time zone and format assumptions | Boundary records at period start and end. |
| Recalculated Derived Fields | The target computes what the source stored | Comparing values rather than formulas. |
| In-Flight Records | Activity during the migration window | Reconciliation after the window closes. |
Ask what the reconciliation plan compares, specifically. If the answer is record counts, the plan detects one of the six differences on this page. If it is counts and control totals, it detects two more and still misses the two that customers see. The remedy is not a bigger plan: it is field-level comparison on a representative sample plus boundary records, which adds days rather than weeks and is the difference between proving the migration and asserting it.
The first question is not which tool. It is how long the business can be without the service, and what it will accept being unavailable rather than wrong. The honest answer to that chooses the migration pattern, and each pattern has a different cost and a different risk profile.
Everything after that is execution discipline: profile the data, agree the quality decisions with their owners, rehearse at full scale, reconcile properly, and name the point of no return before anybody starts.
Step 1
Assess readiness: scope, dependencies, constraints, obligations
Step 2
Analyse source and target, structure by structure
Step 3
Map dependencies, including the consumers of the source
Step 4
Profile the data and surface every quality problem
Step 5
Agree the downtime budget with the business
Step 6
Agree each data quality decision with the data owner
Step 7
Design the reconciliation before the migration logic
Step 8
Build the migration with reprocessing and restartability
Step 9
Pilot on a representative subset and reconcile it fully
Step 10
Rehearse at production volume, end to end, including rollback
Step 11
Cut over against a runbook, with the point of no return timed
Step 12
Reconcile, resolve exceptions, then decommission the source
Ask how long a rollback takes, measured rather than estimated. If the number has not been measured in a rehearsal, the rollback plan is an intention. That matters most at the moment of maximum pressure: a rollback that takes six hours when four remain in the window is not available, and discovering that during the cutover is how a migration becomes an incident.
Grouped by what each part does. The validation group is the deliverable rather than a supporting activity, which is the thing that distinguishes a migration you can evidence from one you can only assert.
Migration execution
Database migration, including version upgrades, platform changes and schema conversion
Application workload migration, with the hosting target designed on our Cloud Modernization page
Cloud migration execution, including the sequencing that keeps dependent workloads together
Data transformation and mapping, held in a mapping catalogue that records every source to target definition and every approved transformation, rather than embedded in a script
Bulk transfer engineering for large data volumes, where throughput determines whether the window holds
Incremental synchronisation and change capture for zero or near-zero downtime patterns
Migration automation, so the run is repeatable, restartable and identical in rehearsal and cutover
Validation and reconciliation
Data profiling before migration, with every quality problem surfaced for an owner’s decision
Reconciliation design: counts per segment, value totals, field comparison and boundary records
Deliberate differences recorded and accounted for, so the residual differences are meaningful
Parallel running and output comparison where the application behaviour is also changing
Exception handling with an owner and an age rather than a report
Cutover
Cutover runbook engineering, timed step by step, with the point of no return in it
Full-volume rehearsal, including the rollback path and its measured duration
Rollback engineering, including the position on activity captured in the target
Cutover orchestration and the communications that go with it, since several teams act in sequence
Post-cutover stabilisation, where the first period end is the real test
Decommissioning
Verification that nothing still calls the source before it is switched off
Source system decommissioning, with the history question resolved per our Legacy Application Modernization page
Licence, support and infrastructure cost termination, which is where the benefit is realised
The mechanics are similar across these. What differs is where the difficulty sits, and naming it in advance is more useful than describing the move.
Core-adjacent data migration
Moving data held in systems that sit directly against the core.
Banking platform consolidation
Two or more systems performing the same function, reduced to one.
Database upgrades and platform changes
Version upgrades, engine changes, or a move to a managed database service.
Cloud workload migration
Moving applications and their data to a cloud target.
Merger and acquisition consolidation
Bringing an acquired institution’s customers, accounts and history onto your platforms.
Lending system migration
Moving facilities, balances, schedules and history to a new servicing platform.
Customer data migration
Moving customer records, contact details, preferences and consents.
Enterprise application transitions
Moving internal platforms: finance, HR, service management, document systems.
In a consolidation, ask both business owners to describe how one fee or one status is handled. If the two descriptions differ, that is a decision the migration will otherwise make silently in a mapping spreadsheet. Running that comparison across the twenty most commonly used rules takes about a week and it produces the decision log the rest of the programme depends on.
We work within your existing tooling and platform decisions. The architecture of a migration is unremarkable; what distinguishes a good one is that the validation is designed first and the pipeline is built to be run repeatedly rather than once.
Extraction
From the source, with a defined point in time and a repeatable method.
Staging
Where the data lands before transformation, so each stage can be inspected.
Transformation
Mapping and conversion, with every interpretation recorded as a decision.
Load
Into the target, restartable, with rejected records captured rather than lost.
Change capture
For incremental patterns, keeping the target current until cutover.
Reconciliation
Counts, totals, field comparison and boundary records, automated.
Orchestration
The runbook as code where possible, so rehearsal and cutover are identical.
Rollback
A path back, with its duration measured in rehearsal.
Extract, transform and load tooling, or extract, load and transform where the target does the work better
Change data capture and replication for incremental synchronisation and dual-run patterns
Schema conversion and mapping tooling, with manual review of everything it generates
Bulk transfer mechanisms appropriate to the volume, including physical transfer where the data is large enough to warrant it
Data quality and profiling tooling, used before the migration rather than after
Staging environments that match production in shape and scale, which is what makes a rehearsal meaningful
A migration temporarily multiplies your most sensitive data: extracts, staging, rehearsal environments, backups taken for safety. Each copy carries the same obligations as the original and usually has fewer controls around it.
Data classification
Applied to every copy the migration creates, including rehearsal data.
Encryption
In transit and at rest, including staging and intermediate files.
Access control
Who can read the extract, with migration access time-bounded.
Audit trail
What was extracted, transformed, loaded, by whom and when.
Reconciliation controls
Evidence retained, including every deliberate difference.
Retention
When every copy the migration created is destroyed, and proof of it.
Privacy and residency
Where copies may exist, which rehearsal environments often breach.
Change approval
Cutover through your change process, with rollback criteria attached.
Modernize banking technology with scalable cloud infrastructure and resilient application platforms. From cloud and legacy application modernization to data migration, DevSecOps, and cloud operations, help banks improve platform reliability, strengthen security, optimize infrastructure costs, and support future growth.
The decision to proceed with a cutover is usually made in a meeting on the basis of confidence. It can be made against evidence instead, and the evidence is available before the meeting.
A full-volume rehearsal completed, with the measured duration inside the agreed window and the slowest step known
Rollback rehearsed, with its duration measured, which is what makes the point of no return a real decision
Reconciliation automated and passing on the rehearsal, with every deliberate difference accounted for
Every data quality decision signed by its owner, with none outstanding
Exceptions from the pilot resolved or explicitly accepted, rather than carried as a list
The runbook timed step by step, with the point of no return and its decision owner named
Dependent systems confirmed ready, including the consumers of the source
A named go or no-go decision owner for the start of the cutover, which is a separate decision and a separate person from the point of no return later in the window
Reconciliation tolerances signed by the business data owners, so the acceptance threshold is agreed before anybody is looking at real differences
And the communication plan agreed, since the first hour after cutover generates questions from several directions
Progress against the timed runbook, so a step running long is visible while there is still time to act
Record counts and value totals as each stage completes rather than only at the end
Rejected records, with the reason, as they occur
Synchronisation lag where an incremental pattern is in use, which is the measure that determines when the window can start
Application stability after cutover: errors, latency and the first batch cycle, which is where residual problems surface
Post-migration exceptions with an owner and an age, not a report
And the first period end, which is the real test of a banking migration and should be treated as part of the programme rather than as business as usual
Ask whether the cutover decision will be made against a checklist or in a meeting. Both involve the same people and take the same hour. The difference is that a checklist can be prepared, evidenced and reviewed in advance, and it makes an uncomfortable answer visible before the weekend rather than during it. Every item on the readiness list in this section can be evidenced before the decision is needed.
Outcomes depend on the data, the window and the state of the source. These are the changes the work is aimed at.
The target can be proved equal to the source, with the differences that remain being the ones somebody chose
The pattern was chosen from the downtime the business agreed rather than from a tool’s capability
Every data quality decision has an owner and is recorded, so the figures can be explained later
The window is known from a full-volume rehearsal rather than estimated
Rollback has a measured duration and a point of no return with a clock time
Cutover is decided against a checklist that was evidenced in advance
Exceptions after cutover have owners and ages rather than accumulating in a report
Copies created by the migration are registered and destroyed, with evidence
And the source is decommissioned, which is where the cost actually comes out
Bring us one migration, planned or already in trouble, and we will profile the data, state the pattern the window actually permits, design the reconciliation, and tell you whether the date is achievable.
CaliberFocus moves banking applications and data with reconciliation as the deliverable. We let the downtime the business will accept choose the pattern, route every data quality decision to its owner, build the migration as a repeatable pipeline rehearsed at full volume, reconcile with six comparisons rather than record counts, and name the point of no return before cutover.
- Six-way reconciliation that proves the target equals the source
- Full-volume rehearsals, including a measured rollback
- A point of no return with a clock time and a named decision owner
- Every migration copy registered and destroyed, with evidence
Security & Compliance
