When issuers begin planning a migration, the conversation tends to focus on the platform: features, APIs, processing capabilities. The data question gets less attention, and when it does come up, it is often framed as a logistics problem. Extract the data, move it across, load it in.
In practice, it is considerably more involved than that. The process of moving cardholder data from one processor to another involves a structured methodology that, when done correctly, protects cardholders from noticing anything has changed at all.
The core methodology is known as ETL: Extract, Transform, and Load. Each stage carries its own complexity.
The extraction is performed by the client or the existing processor. This is the point at which the full dataset needs to be pulled from the legacy system, including every product configuration, cardholder profile, account status, chip parameter, fraud rule set, and tokenisation record. The challenge here is that legacy systems often contain old, unused, or misconfigured records that have sat untouched for years. They are not visible until extraction surfaces them, and they need to be accounted for before transformation begins.
Transformation is where the heavy lifting occurs. Every data value from the legacy system needs to be mapped to its equivalent in the new platform. This is not a like-for-like translation. Legacy processors use different data models, different status codes, and different field structures. Every mapping has to be verified, because a missed or incorrect mapping has a direct effect on cardholder experience after cutover. If a cardholder had blocked international spend before the migration, that setting must carry across exactly. If it does not, the cardholder faces an unexpected decline.
Loading is the final stage, moving the transformed data into the new production environment. By this point, the transformation logic needs to be stable and fully verified, because any issues discovered during loading compress the timeline at the worst possible moment.
From experience, card chip and key setting data, particularly where historic setup details may not be available, are key areas to watch out for. In general, it is data that are not changed so frequently that people make assumptions about. But, you cannot assume anything during migrations.
A principle that experienced migration teams apply is to minimise the data being moved. Legacy processors often hold a large number of fields per cardholder account, many of which are not relevant to the issuer's future product roadmap. Migrating only the fields that are genuinely needed reduces what is sometimes called the error surface: the number of mappings that need to be verified, the volume of data that needs to reconcile, and the complexity of the transformation logic overall.
This is not about cutting corners. It is about applying rigour to what needs to move, so that the process of verifying it is manageable and the risk of something going wrong is reduced.
Once the transformation logic is in place, the temptation is to test on a representative sample: take a portion of the portfolio, run it through the process, identify issues, and fix them. The problem is that dormant and older accounts are precisely where anomalies tend to hide. Those anomalies only surface when the full portfolio is loaded.
Testing on a subset of the portfolio is one of the most common sources of migration problems. The only reliable approach is to extract and test every single account, using real, anonymised data, across multiple rounds of end-to-end testing before the live date.
A disciplined migration process uses strict go/no-go criteria to gate progression to the live event. There are four: mock loads must succeed; reconciliations must match; data volumes and balances must align; and transformation logic must be stable. All four need to be met. None of them are discretionary, and a shortfall in any one of them is a reason to pause, not to proceed and monitor.
The same discipline applies to financial reconciliation. Even in prepay or debit migrations, a single penny mismatch can trigger regulatory audits and erode cardholder trust. In credit scenarios, where balances, interest calculations, fees, and adjustments all need to carry across correctly, the standard is even more exacting.
The ETL process is not something that runs in the background while the rest of the migration is planned. It is the migration. The quality of the transformation logic, the rigour of the testing, and the precision of the reconciliation determine whether cardholders experience anything at all on live day.
Thredd's approach is built around a repeatable, gated ETL process developed across decades of migrations. The minimal data principle, full-portfolio testing, and strict go/no-go criteria are not optional additions to that process. They are the foundation of it.
Want the complete framework? Download the playbook for invisible transitions
Speak to our team about what operational readiness looks like for your specific card program.
