The case against ripping everything out
The majority of financial institutions are not plagued with a modernization problem. They suffer from a visibility problem. The legacy systems are old, of course, but the big blocker is that nobody has sufficient visibility to understand how data flows through those systems. So the systems themselves are old and slow and lack any kind of modern infrastructure compatibility, but they’re also unstable in ways we can’t even predict.
This lack of visibility causes downstream dependencies between services and data across the organization. It means that your replacement or upgrade strategy is the IT equivalent of betting everything you have on a single roll of the dice.
Map before you move
The outdated systems in financial services were not built as complex systems all at a time. The complexity has been accumulating over the decades including acquisitions, regulatory issues, the expansion of product lines. The data connections inside these systems save the history, including mergers and acquisitions, and the relationships you’d rather forget exist. Most institutions have silos they know about, and ones they don’t.
Unveiling and understanding the silos is the fundamental first step in any serious systems consolidation. And it must be real-time silos visibility. Not high level, not in a diagram, but with enough detail that you can identify where specific data sets originate, how they’re transformed in transit, and which downstream systems depend on them. Without that map, you’re making changes to a network you don’t fully understand.
The mechanism that makes this possible is data lineage tracking. Tools like Solidatus let you trace and analyze the movement of a data field from a mainframe database through multiple ETL processes before appearing in a cloud-native reporting tool – a powerful ability when you’re planning a migration project. Knowing all the systems that are affected by a change, and so as a consequence will be broken by it, before you make the change is invaluable.
Build a bridge, not a replacement
The strategy that involves abruptly shutting down the legacy system and turning on the new one has failed so many times that most experts avoid it. The only other viable option left is the strangler pattern, where you migrate the features one by one and allow the new system to gradually subsume that responsibility of the old system and keep the legacy running.
This works because with incremental migration, the blast radius is much smaller. If one module of your financial application withers out for unmet expectations, it’s not that the whole operations is down. You just roll back that module and try again.
Nearly 70% of banks’ IT budget is spent on maintaining legacy systems rather than building new products (McKinsey & Company). And that’s a consistent percent. It shows the difficulty in getting out of the maintenance trap. Incremental migration is not as fast a solution as full replacement but that’s how you get out of that mess.
Wrap the backend with an API layer
You don’t have to modernize everything to make modern applications work with legacy data. An API gateway or middleware solution can isolate the mainframe or other legacy system from the new application, minimizing but not entirely eliminating the need to interface with older, downright archaic infrastructure.
It’s not going all-in but a practical middle ground – buying time for deeper modernization work while delivering immediate value through faster reporting, better integrations, and access to open banking frameworks that require API-accessible data.
Data quality before migration, not after
One of the mistakes made too often during a legacy migration is transplanting bad data into a new environment and then attributing the bad data to a data quality problem. It’s not. It’s a preparation problem, and it’s a very expensive problem to fix post facto.
Legacy financial data comes with years of issues; duplicate records, missing fields, and formatting discrepancies between systems create a backlog of data that has never been cleaned. That should all be done prior to that data entering any shiny new financial software. The new software didn’t create the issue and relying on it to handle and sift through your history of data quality issues is not going to be in any hurry.
Compliance doesn’t pause for migrations
Regulations like BCBS 239 apply regardless of whether you’re midstream with your modernization efforts. And it’s not just about having an audit trail of your lineage. It’s to have that audit trail available unbroken during and after your migration. That’s not trivial, since nothing will have changed more during your modernization than your data, and therefore your data metadata. Should you store it at the source, the target, or both? What structure does it need when 10% or 100% of your data is staged? How do you manage and redraw lineage when the environment structure and even logging conventions differ? These challenges are met with the least disruption when automated lineage is used.
The visibility-first approach
Connecting old systems and new financial tools doesn’t involve technology as much as it does data management. The organizations that are successful do not guess what they have, but rather know exactly what they have – and where the risks lie. They then have the luxury of adapting the infrastructure to the true requirements, without rushing judgement on whether their needs are legacy or modern.
