Financial Data Migration: How We Moved and Tested a US Bank’s Data After a Merger
Last Updated on September 25, 2026
Quick Summary:
This insight walks through a financial data migration we ran for a US regional bank after it acquired a smaller community bank: what we found in the data, what we chose to move, the five checks every record had to pass, and the practices we now bring to every bank conversion.
Table of Contents
Introduction
The conversion weekend was on the calendar before anyone had properly opened the acquired bank’s data. In our experience, that is how most financial data migration work in a bank merger begins.
Our client, a US regional bank with about $9 billion in assets, had bought a community bank roughly a fifth of its size. Customers had letters naming the weekend their accounts would move. Regulators knew the date. What nobody could say with confidence was whether 12 years of customer, deposit, loan, and general ledger data would land on the acquirer’s core intact.
The inherited test plan counted records and spot-checked a few hundred accounts. For a financial data migration covering roughly 140,000 deposit accounts and 11,000 loans, that is not a test plan. It is a hope.
We joined the project 4 months before conversion. Here is what we found, how we moved the data, and how we proved it was right.
Why Financial Data Migration Fails Without Proper Testing
Record counts are the most comforting number in a conversion, and the least useful. You can move every loan and still get the balance wrong on half of them. A count tells you a row arrived. It says nothing about whether the rate, the payment date, or the escrow balance inside it survived the trip.
The UK’s TSB learned this in public. After its 2018 platform move, regulators noted that the data itself migrated successfully, yet the platform failed, and a large share of its 5.2 million customers were affected. The FCA and PRA fined the bank £48.65 million. A financial data migration can pass every transfer check and still fail the bank.
The pressure is rising. US banks announced 181 M&A deals in 2025, the most since 2021, according to S&P Global Market Intelligence. Each one ends in a conversion weekend like this.
What We Found When We Audited the Acquired Bank's Data
We spent the first three weeks reading data, not writing code. Four findings changed the plan.
Duplicate and Incomplete Customer Records
Close to 6% of customer records were duplicates, usually one person with a loan at one branch and a checking account at another. Others had missing dates of birth or addresses typed into a single free-text field. Converted as they were, those records meant two statements, two privacy notices, and a broken link to the KYC file.
A Chart of Accounts and Product Codes That Didn't Match Ours
The acquired bank ran 38 deposit products against the acquirer’s 22, and about 1,900 general ledger accounts had to fold into 1,412. Several fee waivers existed only as notes on the account, not as rules the system enforced. Someone had to decide what each one became.
Transactions Disconnected From Their Accounts
Around 3,000 historical transactions pointed to accounts closed and purged years earlier. Joint holders were stored three different ways depending on when the account was opened. None of this shows up in a record count.
No Agreed Totals to Test Against
This one worried us most. Finance and IT had different month-end totals for the same products, because one pulled figures before the nightly batch and the other after it. Until both agreed what “correct” looked like, there was nothing to test against.
Planning a Core Conversion After an Acquisition?
Work with a financial software development company that has already untangled mismatched charts of accounts and product codes, not one learning on your customers’ data.
Our Step-by-Step Financial Data Migration Process
Once the audit was done, our financial data migration process came down to four steps: decide what moves, choose how to cut over, prove every record is right, and rehearse until the numbers hold. Each step shaped the next one.
Step 1: Decide What to Migrate and How Much History to Move
Every financial data migration forces a choice about history: move only current balances, move everything, or take a middle path. We took the middle path. Customer, account, and loan records moved with 7 years of full transaction history, enough for statement requests and retention needs, and older data went to a searchable read-only archive. For the general ledger, we loaded opening balances plus 24 months of summarized monthly balances, so finance could run year-over-year reports from day one.
Step 2: Choose the Cutover Approach and Plan Full Rehearsals
A big-bang move switches everything in one window. A phased move converts products or branches in waves. A parallel run keeps both systems live and compares them. Phased approaches suit core replacements, as we showed when we modernized a legacy financial system without downtime. A merger is different. A customer cannot be half converted, so one weekend was the only real option, and that put all the risk on rehearsal.
Step 3: Run Five Checks Every Record Must Pass
Record Completeness: Counts and hash totals by product, branch, and account status, not one grand total.
Value Accuracy: Every mapped field compared between systems, including rates, dates, maturity terms, and decimal precision.
Data Relationships: Customers, accounts, joint holders, and transactions still linked, with no orphaned records.
Trial Balance Tie-out: Every general ledger account matched to the cent, with loan and deposit subledgers tied to the ledger.
Business-day Readiness: Branch and operations staff ran a scripted day on the new data, covering deposits, interest accrual, statements, and loan payoff quotes.
Step 4: Run Mock Conversions and Make the Go/No-Go Call
A mock conversion is a full dress rehearsal on a complete copy of production data. We ran four. The first took 41 hours against a 36-hour window, the most useful thing we learned all project long. Go-live needed three conditions, agreed in writing up front: a trial balance that ties out to the cent, zero open critical defects, and a runtime under 30 hours. We rehearsed the rollback during the third mock, because a rollback plan nobody has run is just a document.
Three Problems That Surfaced Mid-Migration
Rehearsals exist to surface problems, and ours did. These three took the most effort to find and fix, and none of them would have shown up in a record count.
Small Rounding Gaps in Loan Interest
The legacy system stored daily interest accrual to five decimal places; the target stored two. On one loan, the gap was a fraction of a cent. Across 11,000 loans, it came to about $1,900. Finance agreed on a rounding rule, and we converted accrued interest as a posted figure instead of recalculating it.
End-of-Day Cutoffs That Split Transactions
The acquired bank closed its business day at 6 p.m.; the acquirer at 9 p.m. Card and ATM activity in that gap landed on different days in each system, so Friday totals never matched. We aligned the cutoff for the conversion weekend and retested on a Friday production copy.
Too Many Mismatches to Review by Hand
Our first full comparison produced more than 40,000 exceptions. Grouped by cause, about 90% traced back to six mapping rules. Fixing the rules, not the rows, made it manageable, and it is the first thing we look for now when a financial data migration throws up a wall of exceptions.
Financial Data Migration Best Practices: We Apply to Every Bank Conversion
None of these practices is new on its own. What changed for us is that we no longer treat any of them as optional, because each one traces back to a problem we hit on this conversion or caught just in time. If you take one section from this insight into your own financial data migration testing plans, make it this one.
Clean and Deduplicate Data Before Mapping Starts
Cleansing after mapping means mapping twice. Merge duplicate customers, fill mandatory fields, and retire dead products in the source first. Every financial data migration we run now opens with a cleanup sprint, and the mapping that follows moves noticeably faster.
Agree on Control Totals With Finance Before Testing
Without agreed totals, every mismatch becomes a debate. Fix the totals for each product and ledger early, including the exact snapshot time. The same discipline drives our financial services data analytics work, where two teams reporting different numbers is a familiar starting point.
Test Every Real Record
Sampling is fine for phone numbers. It is not fine for balances, rates, or accrued interest. Our rounding gap would never have appeared in a sample of 500 loans.
Mask Customer Data by Default in Every Test Environment
Every test environment is another copy of customer data, and the financial sector’s average breach cost was $5.56 million in 2025. We mask names, account numbers, and tax IDs everywhere except the locked-down rehearsal environment, which also supports the bank’s Gramm-Leach-Bliley Act obligations. Our financial services cybersecurity team sets those masking and access rules before the first test environment exists.
Rehearse the Full Conversion
The first rehearsal shows what breaks. The second shows whether the fixes held. We now plan at least three for any financial data migration at a bank, each at full volume and timed against the real window.
Keep an Audit-Ready Record of Every Check
Examiners will ask how you know the conversion was right. Log every test, its result, who signed it off, and when. Here, that record turned a post-conversion audit request into an afternoon’s work.
Need Proof Your Migrated Data is Right Before Go-Live?
Our financial software testing services team builds reconciliation-first test plans, mock conversions, and audit-ready evidence for banks heading into a financial data migration.
Results of the Financial Data Migration After Go-Live
Measure
First rehearsal
Final rehearsal
Go-live weekend
First 90 days
GL accounts tied out to the cent
1,261 of 1,412
1,412 of 1,412
1,412 of 1,412
1,412 of 1,412
Open critical defects
37
0
0
0
Conversion runtime
41 hours
27 hours
28 hours
Not applicable
Customer-facing balance errors
Not applicable
Not applicable
0
3 & all fixed within a day
One thing did not go to plan. About 2,300 dormant accounts carried unclaimed property flags in a field we had mapped as informational. They surfaced on day two, and we corrected them well before any statutory deadline. That field is now a standing item on our mapping checklist.
Conclusion
We moved data in just 28 hours, but the real work was the 4 months we spent before migration. It proved that every balance, every link, and every ledger account would come out exactly as it went in.
Financial data migration testing doesn’t get that much attention. Moving data is an engineering task, but proving it moved correctly is what lets a bank’s leadership, auditors, and regulators say yes to go-live with confidence.
If your bank is heading into a merger or a core change, start with the evidence and build the move around it. That is how our financial IT services and solutions team plans every conversion.
Financial data migration is moving ledgers, transactions, customer records, and account data from one system to another without losing accuracy, history, or audit trails. Banks usually do it during mergers, core replacements, or cloud moves.
For a mid-size bank, planning and testing typically take three to six months, while cutover runs over one weekend. Poor data quality, many products, and long histories stretch the timeline most.
Near-zero downtime is possible with phased or parallel approaches. Merger conversions usually accept a planned weekend outage, because customers need to move all at once.
Most banks move 5 to 7 years of full history to cover statement requests and retention rules, and archive the rest in a searchable read-only store. For the general ledger, opening balances plus summarized history is common.
Financial data migration testing starts with comparing record counts and hash totals, then matching every general ledger account to the cent and tying loan and deposit subledgers back to the ledger. Every difference is traced to its cause before sign-off.
AWS Database Migration Service, Azure Data Factory, and Informatica are common for moving data, with Great Expectations, dbt tests, and Python comparison scripts for validation. Our guide to data migration tools compares the main options.
Migration moves data between systems. Conversion changes its format or structure to fit the target, such as mapping old product codes to new ones. Most bank projects need both.
Hiral Pandya
Lead Software Engineer at Bacancy
DevOps leader optimizing cloud infrastructure and driving scalable engineering innovation.
