.jpg)
The modernisation dilemma
22 Jul 2026
As asset servicers face growing demands for faster processing, greater automation, and real-time data, decades-old technology is coming under increasing strain. Zarah Choudhary explores whether the solution lies in optimising existing infrastructure, building around it, or finally leaving legacy technology behind
Image: agratitudesign/stock.adobe.com
Built to last
Legacy technology has long been framed as a problem waiting to be solved. Across financial services, ageing systems are frequently blamed for high maintenance costs, fragmented data, and an inability to integrate easily with newer technologies.
Yet their continued existence is not simply the result of firms resisting change.
Many remain because they continue to perform the functions they were designed to do. Systems supporting fund accounting, investor servicing, settlement, reconciliation, and corporate actions have processed transactions through market crises, regulatory changes, and enormous increases in volume.
“The simple answer is that most legacy platforms still do the job they were built to do,” says Chris Edwards, senior managing director and head of IMS client enablement at SEI.
Russell Andrews, head of wealth and asset management at FIS, agrees that reliability is a significant factor.
“These platforms process huge amounts of activity reliably every day, so firms are understandably cautious about replacing them,” he explains. “The challenge isn’t that legacy systems are broken, it’s that they weren’t designed for today’s demands around data, real-time processing and interoperability.”
Thomas Steinborn, chief product and technology officer at Smartstream, similarly adds the cost and risk of replacement have historically outweighed the benefits, particularly for systems underpinning mission-critical processes where the tolerance for disruption is close to zero.
Saugat Nayak, data science and risk analytics specialist and machine learning researcher, argues that reliability itself has become a barrier to change.
“Legacy systems persist because they work, and in financial services, something that works is extremely hard to justify upgrading,” he notes.
For Murray Campbell, principal product manager at AutoRek, firms must also contend with more immediate priorities. Operations departments have accumulated a complex web of systems and controls while simultaneously dealing with business-as-usual requirements, regulatory change, and client demands.
“The priority for most firms is very much on completing business as usual operational processes to service their clients, and the additional time available to enhance systems and processes outside of that can be scarce,” he states.
Where existing technology continues to deliver the required outcome, transformation can therefore struggle to compete for investment.
The weight of complexity
Reliability, however, does not mean legacy infrastructure comes without cost.
J.P. Morgan describes technical debt as the additional cost incurred through inefficient technology systems and processes, encompassing ongoing maintenance, the people required to complete tasks, and the complexity of the underlying infrastructure.
Over time, that burden can extend far beyond the original platform.
“These systems rarely operate in isolation,” Edwards says. “They’re connected to dozens, sometimes hundreds, of downstream processes and applications, so replacing one platform often means touching a much larger ecosystem.”
Nayak describes the same problem as “downstream dependency creep”.
“Every report, every data pipeline, every dashboard built on top of a legacy system creates a new dependency that makes change more expensive and more risky,” he explains. “You’re not just migrating a system. You’re migrating an ecosystem.”
Andrews similarly identifies complexity as the biggest operational challenge. Decades of customisation and interconnected processes can make integration expensive while leaving data fragmented and creating dependence on a shrinking group of people who understand the underlying architecture.
“Legacy platforms are not built on an infrastructure that is conducive with open architecture workflow connectivity through APIs, and the data can also be hard to extract in a real-time, trigger-based and native way,” he observes.
Campbell adds that older platforms are often built for a single purpose and lack the flexibility required to support new data sources, formats or use cases. Where systems cannot adapt, spreadsheets and manual workarounds are introduced around them, creating additional resource demands.
Steinborn says manual intervention and break resolution can absorb up to 70 per cent of operational effort in some environments. The risk is compounded by specialist knowledge that has accumulated over decades but may never have been formally documented.
“The undocumented expertise that once held these processes together is walking out of the door faster than it can be replaced,” he warns.
Security can further undermine the argument that functioning technology should simply be left untouched. Steinborn points to systems running on operating systems, databases, or middleware that vendors no longer support or patch.
“A system can function perfectly well operationally while representing an unacceptable security exposure,” he states.
Replace, optimise, or rebuild?
While the need for modernisation is increasingly difficult to dispute, there is less consensus about what modernisation should actually mean.
“Large institutions rely on highly interconnected systems, so full ‘rip and replace’ programmes are risky, slow, and disruptive,” says Ian Salmon, head of product marketing at Adaptive.
Andrews similarly says most firms have recognised that wholesale replacement is difficult to justify.
“Instead, we’re seeing a much more pragmatic approach focused on modernising incrementally, leveraging APIs, cloud technologies, and solutions that allow firms to evolve while protecting existing investments.”
Edwards describes this as “modernising around the core”, with organisations introducing better data architecture, cloud capabilities, automation, and APIs without necessarily replacing every underlying platform.
“The reason is straightforward: it reduces risk, lowers cost, and delivers business value much faster,” he informs.
Research into financial-sector cloud migration reflects this more selective approach. Strategies range from relatively limited lift-and-shift migrations to re-platforming and complete refactoring, while hybrid models allow institutions to retain critical components and introduce cloud capabilities gradually.
Steinborn says the industry has learned “often painfully” from large-scale replacement programmes.
“Firms are increasingly asking not, ‘how do we replace this?’ but ‘how do we make this fit for purpose for where the market is heading?’”
Campbell, however, cautions against assuming optimisation has universally overtaken replacement.
“This is not a significant change in direction that we have witnessed, and we still regularly work with firms to replace the existing software platforms they are using,” he notes.
Where a platform lacks the flexibility to support new requirements, continued optimisation may eventually become less practical than replacement. The challenge is determining where that line sits.
Building around the core
Where firms choose to retain existing infrastructure, connectivity is becoming central to extending its capabilities.
For Nayak, API stacking is among the most realistic approaches.
“It allows current programmes to communicate with legacy systems without touching the core,” he says.
He points to his experience of a migration to Snowflake where the reporting and analytics layer was modernised while the underlying transaction-processing infrastructure remained untouched.
“It’s not glamorous but it’s realistic.”
Steinborn similarly argues that the most effective approaches “add capability without destabilising the core”, pointing to API layers, middleware, hybrid deployment models, data platforms, and workflow orchestration.
Salmon highlights modular architecture and scalable messaging infrastructure as another route, allowing modern services to integrate with older platforms while limiting migration risk.
Andrews identifies API-led architectures, cloud deployment models, real-time data platforms, and workflow automation as particularly effective.
“The goal is often not to replace the core system immediately, but to surround it with modern capabilities that improve agility and create a pathway to future transformation,” he explains.
Highly modular and configurable software, he adds, can allow firms to adopt new capabilities incrementally rather than undertaking a single high-risk migration.
For Edwards, the most important foundation may be data.
“Unified data platforms, cloud-based analytics environments, API frameworks, workflow automation tools, and event-driven architectures provide firms with the ability to unlock value from systems that were never designed to work together,” he says.
The challenge, then, is not necessarily to make every component modern. It is to ensure the wider architecture can operate as though it is.
Intelligence needs foundations
AI is adding another dimension to this strategy, although contributors warn against treating it as a cure for outdated infrastructure.
Nayak says AI can identify data-quality issues, map dependencies, and detect reconciliation breaks. Yet it cannot always determine why an older system behaves as it does.
“If the rules that underlie a computation are simply code written 15 years ago by someone who has moved on to another firm, then AI is able to read the code, but it can’t tell you whether that logic is reflective of current business intent,” he explains.
Salmon similarly argues that AI can improve analysis, testing and code generation, while questions around architecture, resilience, and accountability remain human responsibilities.
Steinborn sees considerable potential in using AI to address exception-heavy processes and capture institutional knowledge, but warns: “AI extends and enhances well-run infrastructure; it does not rescue a broken foundation.”
Edwards makes the same point from a data perspective.
“If a firm’s data is fragmented across multiple systems and governed inconsistently, AI doesn’t solve that problem, it only exposes it,” he informs.
Andrews also sees a role for AI during the migration process itself. Beyond automating reconciliation, exception management, and data enrichment, AI could accelerate data transfers, identify anomalies, and support automated corrections.
“This could materially improve the speed of the migration while reducing risks,” he suggests.
Campbell, meanwhile, argues AI may ultimately create opportunities to replace legacy solutions rather than simply extend them.
The market will not wait
Whatever strategy firms pursue, external pressure is making delay increasingly difficult.
Shorter settlement cycles, real-time processing, and tokenisation are placing demands on technology stacks built for a different operating environment.
The move towards T+1 compresses the time available for trade processing, reconciliation, and exception resolution, while real-time expectations increasingly challenge architectures designed around overnight batch cycles.
“These market changes fundamentally reduce the margin for operational delay,” Andrews says.
“Processes that were designed around overnight batch cycles increasingly need to operate in near real time.”
Steinborn similarly says the market is moving towards immediacy while much of its underlying infrastructure was “built for a slower, more manual world”.
Edwards argues these developments expose “the limits of batch-based operating models”, with the pressure extending beyond technology to data, workflows, controls, and the broader operating model.
Nayak says shorter cycles are “fundamentally redefining the tolerance for latency”, while Salmon points to growing demands for always-on performance and interoperability across traditional and blockchain-based environments.
For Campbell, external deadlines can finally provide the business case operational teams need to secure investment.
“The move to T+1 is certainly one such example of that, where manual processes will no longer be sufficient to meet the operational demands of the shortened settlement cycle,” he says.
Changing without breaking
Modernisation ultimately confronts asset servicers with a delicate challenge: how to change infrastructure without jeopardising the processes it supports.
For Salmon, this means “phased delivery, parallel running, and thorough end-to-end testing before moving live operations to new infrastructure”.
Nayak is more direct.
“Parallel running is a must-have for mission-critical systems,” he informs. “Coexisting legacy and modern environments and comparing their outputs prior to cutover is expensive and unsexy but it’s the only way to maintain operational resilience during transition.”
Andrews similarly argues that successful firms treat modernisation as a journey rather than a single transformation programme, delivering tangible outcomes incrementally while keeping resilience, and client service at the centre.
Campbell says technology should itself be viewed as an enabler of resilience, particularly where it removes dependence on manual processes, but firms must conduct sufficient due diligence and testing when introducing new platforms.
Steinborn describes a model of “progressive trust”, where new capabilities earn greater autonomy gradually and decisions remain controlled, explainable and auditable.
“In post-trade processing, resilience is the innovation that matters most,” he states. “A system that is faster or richer in features but less predictable is a poor trade.”
Looking ahead, few expect every legacy platform to disappear.
Steinborn predicts “coexistence rather than extinction”, while Nayak expects layered architectures where modern technology supports new capabilities around proven transaction-processing cores. Campbell foresees a broader spectrum, with firms adopting technology according to their individual ambitions and operating models.
Edwards argues modernisation itself should be understood as an ongoing capability rather than a destination.
Andrews reaches a similar conclusion.
“The winners will be those that can integrate the best of both worlds, combining proven operational stability with modern technology capabilities.”
Some systems will be wrapped in new capabilities, others will operate alongside modern platforms and some will eventually become impossible to justify retaining. The challenge for asset servicers is not simply deciding whether legacy technology should survive, but understanding which foundations remain worth building upon — and ensuring that the infrastructure surrounding them can keep pace with a market that will not wait.
Legacy technology has long been framed as a problem waiting to be solved. Across financial services, ageing systems are frequently blamed for high maintenance costs, fragmented data, and an inability to integrate easily with newer technologies.
Yet their continued existence is not simply the result of firms resisting change.
Many remain because they continue to perform the functions they were designed to do. Systems supporting fund accounting, investor servicing, settlement, reconciliation, and corporate actions have processed transactions through market crises, regulatory changes, and enormous increases in volume.
“The simple answer is that most legacy platforms still do the job they were built to do,” says Chris Edwards, senior managing director and head of IMS client enablement at SEI.
Russell Andrews, head of wealth and asset management at FIS, agrees that reliability is a significant factor.
“These platforms process huge amounts of activity reliably every day, so firms are understandably cautious about replacing them,” he explains. “The challenge isn’t that legacy systems are broken, it’s that they weren’t designed for today’s demands around data, real-time processing and interoperability.”
Thomas Steinborn, chief product and technology officer at Smartstream, similarly adds the cost and risk of replacement have historically outweighed the benefits, particularly for systems underpinning mission-critical processes where the tolerance for disruption is close to zero.
Saugat Nayak, data science and risk analytics specialist and machine learning researcher, argues that reliability itself has become a barrier to change.
“Legacy systems persist because they work, and in financial services, something that works is extremely hard to justify upgrading,” he notes.
For Murray Campbell, principal product manager at AutoRek, firms must also contend with more immediate priorities. Operations departments have accumulated a complex web of systems and controls while simultaneously dealing with business-as-usual requirements, regulatory change, and client demands.
“The priority for most firms is very much on completing business as usual operational processes to service their clients, and the additional time available to enhance systems and processes outside of that can be scarce,” he states.
Where existing technology continues to deliver the required outcome, transformation can therefore struggle to compete for investment.
The weight of complexity
Reliability, however, does not mean legacy infrastructure comes without cost.
J.P. Morgan describes technical debt as the additional cost incurred through inefficient technology systems and processes, encompassing ongoing maintenance, the people required to complete tasks, and the complexity of the underlying infrastructure.
Over time, that burden can extend far beyond the original platform.
“These systems rarely operate in isolation,” Edwards says. “They’re connected to dozens, sometimes hundreds, of downstream processes and applications, so replacing one platform often means touching a much larger ecosystem.”
Nayak describes the same problem as “downstream dependency creep”.
“Every report, every data pipeline, every dashboard built on top of a legacy system creates a new dependency that makes change more expensive and more risky,” he explains. “You’re not just migrating a system. You’re migrating an ecosystem.”
Andrews similarly identifies complexity as the biggest operational challenge. Decades of customisation and interconnected processes can make integration expensive while leaving data fragmented and creating dependence on a shrinking group of people who understand the underlying architecture.
“Legacy platforms are not built on an infrastructure that is conducive with open architecture workflow connectivity through APIs, and the data can also be hard to extract in a real-time, trigger-based and native way,” he observes.
Campbell adds that older platforms are often built for a single purpose and lack the flexibility required to support new data sources, formats or use cases. Where systems cannot adapt, spreadsheets and manual workarounds are introduced around them, creating additional resource demands.
Steinborn says manual intervention and break resolution can absorb up to 70 per cent of operational effort in some environments. The risk is compounded by specialist knowledge that has accumulated over decades but may never have been formally documented.
“The undocumented expertise that once held these processes together is walking out of the door faster than it can be replaced,” he warns.
Security can further undermine the argument that functioning technology should simply be left untouched. Steinborn points to systems running on operating systems, databases, or middleware that vendors no longer support or patch.
“A system can function perfectly well operationally while representing an unacceptable security exposure,” he states.
Replace, optimise, or rebuild?
While the need for modernisation is increasingly difficult to dispute, there is less consensus about what modernisation should actually mean.
“Large institutions rely on highly interconnected systems, so full ‘rip and replace’ programmes are risky, slow, and disruptive,” says Ian Salmon, head of product marketing at Adaptive.
Andrews similarly says most firms have recognised that wholesale replacement is difficult to justify.
“Instead, we’re seeing a much more pragmatic approach focused on modernising incrementally, leveraging APIs, cloud technologies, and solutions that allow firms to evolve while protecting existing investments.”
Edwards describes this as “modernising around the core”, with organisations introducing better data architecture, cloud capabilities, automation, and APIs without necessarily replacing every underlying platform.
“The reason is straightforward: it reduces risk, lowers cost, and delivers business value much faster,” he informs.
Research into financial-sector cloud migration reflects this more selective approach. Strategies range from relatively limited lift-and-shift migrations to re-platforming and complete refactoring, while hybrid models allow institutions to retain critical components and introduce cloud capabilities gradually.
Steinborn says the industry has learned “often painfully” from large-scale replacement programmes.
“Firms are increasingly asking not, ‘how do we replace this?’ but ‘how do we make this fit for purpose for where the market is heading?’”
Campbell, however, cautions against assuming optimisation has universally overtaken replacement.
“This is not a significant change in direction that we have witnessed, and we still regularly work with firms to replace the existing software platforms they are using,” he notes.
Where a platform lacks the flexibility to support new requirements, continued optimisation may eventually become less practical than replacement. The challenge is determining where that line sits.
Building around the core
Where firms choose to retain existing infrastructure, connectivity is becoming central to extending its capabilities.
For Nayak, API stacking is among the most realistic approaches.
“It allows current programmes to communicate with legacy systems without touching the core,” he says.
He points to his experience of a migration to Snowflake where the reporting and analytics layer was modernised while the underlying transaction-processing infrastructure remained untouched.
“It’s not glamorous but it’s realistic.”
Steinborn similarly argues that the most effective approaches “add capability without destabilising the core”, pointing to API layers, middleware, hybrid deployment models, data platforms, and workflow orchestration.
Salmon highlights modular architecture and scalable messaging infrastructure as another route, allowing modern services to integrate with older platforms while limiting migration risk.
Andrews identifies API-led architectures, cloud deployment models, real-time data platforms, and workflow automation as particularly effective.
“The goal is often not to replace the core system immediately, but to surround it with modern capabilities that improve agility and create a pathway to future transformation,” he explains.
Highly modular and configurable software, he adds, can allow firms to adopt new capabilities incrementally rather than undertaking a single high-risk migration.
For Edwards, the most important foundation may be data.
“Unified data platforms, cloud-based analytics environments, API frameworks, workflow automation tools, and event-driven architectures provide firms with the ability to unlock value from systems that were never designed to work together,” he says.
The challenge, then, is not necessarily to make every component modern. It is to ensure the wider architecture can operate as though it is.
Intelligence needs foundations
AI is adding another dimension to this strategy, although contributors warn against treating it as a cure for outdated infrastructure.
Nayak says AI can identify data-quality issues, map dependencies, and detect reconciliation breaks. Yet it cannot always determine why an older system behaves as it does.
“If the rules that underlie a computation are simply code written 15 years ago by someone who has moved on to another firm, then AI is able to read the code, but it can’t tell you whether that logic is reflective of current business intent,” he explains.
Salmon similarly argues that AI can improve analysis, testing and code generation, while questions around architecture, resilience, and accountability remain human responsibilities.
Steinborn sees considerable potential in using AI to address exception-heavy processes and capture institutional knowledge, but warns: “AI extends and enhances well-run infrastructure; it does not rescue a broken foundation.”
Edwards makes the same point from a data perspective.
“If a firm’s data is fragmented across multiple systems and governed inconsistently, AI doesn’t solve that problem, it only exposes it,” he informs.
Andrews also sees a role for AI during the migration process itself. Beyond automating reconciliation, exception management, and data enrichment, AI could accelerate data transfers, identify anomalies, and support automated corrections.
“This could materially improve the speed of the migration while reducing risks,” he suggests.
Campbell, meanwhile, argues AI may ultimately create opportunities to replace legacy solutions rather than simply extend them.
The market will not wait
Whatever strategy firms pursue, external pressure is making delay increasingly difficult.
Shorter settlement cycles, real-time processing, and tokenisation are placing demands on technology stacks built for a different operating environment.
The move towards T+1 compresses the time available for trade processing, reconciliation, and exception resolution, while real-time expectations increasingly challenge architectures designed around overnight batch cycles.
“These market changes fundamentally reduce the margin for operational delay,” Andrews says.
“Processes that were designed around overnight batch cycles increasingly need to operate in near real time.”
Steinborn similarly says the market is moving towards immediacy while much of its underlying infrastructure was “built for a slower, more manual world”.
Edwards argues these developments expose “the limits of batch-based operating models”, with the pressure extending beyond technology to data, workflows, controls, and the broader operating model.
Nayak says shorter cycles are “fundamentally redefining the tolerance for latency”, while Salmon points to growing demands for always-on performance and interoperability across traditional and blockchain-based environments.
For Campbell, external deadlines can finally provide the business case operational teams need to secure investment.
“The move to T+1 is certainly one such example of that, where manual processes will no longer be sufficient to meet the operational demands of the shortened settlement cycle,” he says.
Changing without breaking
Modernisation ultimately confronts asset servicers with a delicate challenge: how to change infrastructure without jeopardising the processes it supports.
For Salmon, this means “phased delivery, parallel running, and thorough end-to-end testing before moving live operations to new infrastructure”.
Nayak is more direct.
“Parallel running is a must-have for mission-critical systems,” he informs. “Coexisting legacy and modern environments and comparing their outputs prior to cutover is expensive and unsexy but it’s the only way to maintain operational resilience during transition.”
Andrews similarly argues that successful firms treat modernisation as a journey rather than a single transformation programme, delivering tangible outcomes incrementally while keeping resilience, and client service at the centre.
Campbell says technology should itself be viewed as an enabler of resilience, particularly where it removes dependence on manual processes, but firms must conduct sufficient due diligence and testing when introducing new platforms.
Steinborn describes a model of “progressive trust”, where new capabilities earn greater autonomy gradually and decisions remain controlled, explainable and auditable.
“In post-trade processing, resilience is the innovation that matters most,” he states. “A system that is faster or richer in features but less predictable is a poor trade.”
Looking ahead, few expect every legacy platform to disappear.
Steinborn predicts “coexistence rather than extinction”, while Nayak expects layered architectures where modern technology supports new capabilities around proven transaction-processing cores. Campbell foresees a broader spectrum, with firms adopting technology according to their individual ambitions and operating models.
Edwards argues modernisation itself should be understood as an ongoing capability rather than a destination.
Andrews reaches a similar conclusion.
“The winners will be those that can integrate the best of both worlds, combining proven operational stability with modern technology capabilities.”
Some systems will be wrapped in new capabilities, others will operate alongside modern platforms and some will eventually become impossible to justify retaining. The challenge for asset servicers is not simply deciding whether legacy technology should survive, but understanding which foundations remain worth building upon — and ensuring that the infrastructure surrounding them can keep pace with a market that will not wait.
NO FEE, NO RISK
100% ON RETURNS If you invest in only one asset servicing news source this year, make sure it is your free subscription to Asset Servicing Times
100% ON RETURNS If you invest in only one asset servicing news source this year, make sure it is your free subscription to Asset Servicing Times
