Modernise, Integrate or Replace? A Decision Framework for Legacy Asset Management Systems

One of the most expensive mistakes an asset manager can make is replacing the wrong system.

When operational complexity starts to slow a business down, it's tempting to point the finger at the oldest application in the technology estate. The logic seems straightforward: if a system feels outdated, replacing it must be the answer.

In reality, it rarely is.

Many legacy systems continue to perform exactly the job they were designed to do. They calculate accurately, hold trusted data, support specialist business processes and integrate with critical third parties. The problem often isn't the system itself. It's everything that has grown up around it.

Over time, manual workarounds creep in. Spreadsheets bridge gaps between applications. Teams coordinate approvals through email. Data is copied, reformatted and reconciled as it moves from one process to another. What began as sensible tactical fixes gradually become part of the operating model.

Eventually, the organisation reaches a point where every change feels harder than it should. Launching a new fund takes longer. Updating product data involves multiple teams. Regulatory reporting becomes increasingly dependent on manual intervention. Yet the underlying systems may still be doing their core jobs perfectly well.

This is where many technology programmes go wrong.

They focus on replacing the most visible system rather than diagnosing the real source of operational friction. The result is often an expensive implementation that leaves many of the original problems untouched because the real issue wasn't the application, it was the way information, decisions and work flowed between applications.

The question therefore isn't "Which system should we replace?", it's "Which systems still create value, and where is operational complexity actually coming from?"

That's a very different conversation.

A Better Way to Think About Legacy Technology

Not every system deserves the same treatment.

Some continue to deliver significant business value and simply need better integration. Others perform well but are surrounded by fragmented manual processes that would benefit from stronger workflow and governance. Some have reached the end of their useful life and can be replaced without affecting the wider operating model. Only a minority require wholesale platform transformation.

The challenge is identifying which category each system falls into.

A practical assessment begins with three questions:

1. Does this system still provide meaningful business value?

2. Is it creating material operational or technical problems?

3. Are those problems isolated to this system, or are they symptoms of wider operational complexity?

The first question is often overlooked.

Business value isn't determined by the age of a system. A twenty-year-old portfolio accounting platform may still perform complex calculations with exceptional reliability. A product master may remain the trusted source of critical reference data. Replacing either simply because they're old could introduce significant cost and risk with very little operational benefit.

The second question separates technical issues from operational ones.

Technical problems include unsupported software, security concerns, limited scalability or architectures that make change increasingly difficult.

Operational problems look very different. Repeated data entry, disconnected approvals, manual reconciliations, inconsistent version control and limited visibility over work in progress often have little to do with the core application itself.

Finally, it's important to understand the scale of the problem.

Is one application genuinely holding the business back? Or has complexity emerged because dozens of systems, spreadsheets and manual processes have evolved independently over time?

The answer to those three questions usually points towards one of four strategic responses. 

A Practical Decision Framework

Business Value	Operational or Technical Position	Recommended Strategy
High	The system performs well but connectivity is limited.	Retain and integrate
High	The core system remains reliable, but surrounding processes rely on manual coordination, approvalsand offline controls.	Wrap with a workflow layer
Low or declining	One application has become the bottleneck while the wider architecture remains sound.	Replace an isolated component
Low across multiple systems	Fragmentation affects data, workflows, governanceand integration across the operating model.	Undertake broader platform transformation

The framework isn't intended to produce a mechanical answer. Technology decisions should always consider factors such as cost, risk, internal capability, regulatory obligations and long-term business strategy.

What it does provide is a more disciplined way of thinking about modernisation.

Instead of assuming every legacy application should be replaced, firms can make different decisions for different systems, preserving what still delivers value, improving what surrounds it, replacing only where necessary, and transforming only when the operating model itself demands it.

For most boutique asset managers, that leads to a more proportionate strategy, lower execution risk and a far greater return on technology investment.

1. Retain and Integrate

Choose this approach when the system still delivers real business value, but the way it connects to the rest of the organisation is creating unnecessary effort.

Not every legacy application is a liability. Many remain highly effective at the specialist task they were built to perform. A portfolio accounting platform may calculate valuations accurately. An IBOR may remain the trusted source for investment data. A transfer agency platform may continue to support critical operational processes.

Replacing these systems simply because they're old can introduce significant cost, disruption and implementation risk without addressing the underlying operational challenges. The real problem often lies elsewhere.

Information is exported into spreadsheets, reformatted for downstream systems, manually reconciled and distributed across multiple teams. Each additional hand-off introduces delay, operational risk and opportunities for error.

In these situations, improving connectivity often delivers greater value than replacing the application itself.

Modern APIs, integration services and governed data flows can allow trusted information to move seamlessly between systems while preserving the proven capabilities that already exist.

Retention should therefore be viewed as an active strategic decision, not a failure to modernise. The objective isn't to keep legacy technology for its own sake; it's to preserve valuable capabilities while removing the operational friction that surrounds them.

2. Wrap with a Workflow Layer

Choose this approach when the application works, but the process around it doesn't.

Many operational problems have very little to do with technology, they're caused by fragmented workflows.

Consider a simple product change. Updating a benchmark, management fee or fund objective may require input from Product, Operations, Compliance, Legal, Marketing and external service providers. The underlying product data may be accurate throughout, yet the process still depends on emails, spreadsheets, meetings and manual follow-ups to ensure every task is completed.

The technology isn't failing, the coordination is. This is where a workflow layer becomes valuable.

Rather than replacing the underlying applications, it orchestrates the work between them. Tasks are assigned automatically, business rules determine who approves what, deadlines are monitored, exceptions are escalated and every decision is recorded, providing a complete audit trail.

For boutique asset managers, this approach often delivers significant operational improvements without the cost and risk of replacing multiple core systems.

It is particularly effective for activities such as fund launches, product changes, document production, distributor onboarding and regulatory reporting, where success depends less on individual applications than on how effectively people, processes and systems work together.

3. Replace an Isolated Component

Choose this approach when one application has clearly become the bottleneck, but the wider operating model remains sound. Sometimes replacement really is the right answer, the key is making sure you're replacing the right thing.

An ageing document production platform, for example, may rely on outdated technology, extensive manual formatting or specialist knowledge held by only one or two employees. If the surrounding data and processes remain reliable, replacing that single capability can deliver significant efficiency gains without triggering a wider transformation programme.

The same principle may apply to regulatory reporting software, reconciliation tools, client portals or internally developed applications that have become difficult to support.

Before replacing any component, however, firms should understand exactly what it does.

Older systems often contain years of embedded business rules, validations and operational knowledge that have never been formally documented. Removing the application without preserving those rules simply recreates the same problems in a newer platform.

Successful replacement therefore starts with understanding dependencies before selecting technology. When properly scoped, targeted replacement reduces execution risk while delivering measurable operational improvements.

4. Undertake Broader Platform Transformation

Choose this approach when the operating model, not an individual system, has become the problem.

Sometimes complexity reaches a point where isolated improvements are no longer enough. Product data exists in multiple locations, different teams maintain different versions of the same information, workflows are fragmented, reporting depends on manual reconciliations and approvals happen outside core systems.

No single application provides an accurate picture of work in progress.

Replacing one system in isolation may improve a specific process, but it won't address the underlying causes of operational complexity. That's when broader platform transformation becomes appropriate.

The starting point should never be technology. It should be the operating model the firm wants to create.

Firms need to question:

• How should product data be governed?

• Where should operational ownership sit?

• How should work flow between teams?

• Which controls should be embedded within processes rather than relying on manual intervention?

Only once those questions have been answered should technology decisions follow.

For boutique asset managers, this doesn't have to mean a multi-year transformation programme. Many successful programmes begin with a single high-value workflow or trusted data domain before expanding incrementally across the wider organisation.

The objective isn't wholesale replacement, it's creating an operating environment in which data, workflows, governance and technology work together as a coherent whole.

Diagnose the Operating Model Before Selecting the Technology

Technology decisions are only as good as the diagnosis that precedes them.

Many transformation programmes begin by evaluating software. The more useful starting point is understanding how work actually gets done. Process maps and application inventories only tell part of the story.

Operational complexity usually lives elsewhere - in spreadsheets, email chains, manual reconciliations, duplicated data, offline approvals and undocumented workarounds that have evolved over time. These activities rarely appear on architecture diagrams, yet they often determinehow efficiently the organisation operates.

Before deciding whether to retain, integrate, replace or transform, firms should assess five areas.

• Business value Does the system still provide capabilities that the business genuinely depends upon? Does it hold trusted data, perform specialist calculations or support critical operational processes?

• Operational effort How much manual work exists around the application? How often is information rekeyed, reconciled, reformatted or passed between teams?

• Technical health Can the system continue to be supported, secured and enhanced with confidence, or is it becoming increasingly difficult to maintain?

• Dependencies Which downstream processes, external providers and regulatory obligations rely upon the system? What would be affected if it changed?

• Proportionality Is the proposed investment proportionate to the problem being solved, or is the organisation considering replacing a valuable system simply because it's the most visible source of frustration?

  
  

Answering these questions often changes the conversation.

A system initially labelled as "legacy" may prove to be one of the most valuable assets in the technology estate. Equally, a relatively modern application may emerge as the real source of operational complexity because it doesn't integrate effectively with the wider operating model.

The objective isn't to identify the oldest technology, it's to identify where change will have the greatest operational impact.

Where an Operating System for Asset Management Fits

For many boutique asset managers, the biggest challenge isn't a lack of capable systems, it's a lack of coordination between them.

Core applications perform specialist functions. Product data resides in multiple locations. Workflows span departments. Regulatory obligations continue to grow. Yet the operational layer connecting these activities often depends on manual intervention.

This is where an operating system for asset management adds value - it doesn't seek to replace every application, it orchestrates them.

By connecting data, workflows, approvals and governance across existing systems, an operating system provides the visibility and control needed to manage end-to-end operational processes. Information moves more consistently. Decisions become auditable. Business rules are applied automatically. Teams spend less time coordinating work and more time completing it.

Within the decision framework described in this article, that means an operating system can support all four strategies.

It can integrate valuable legacy applications.

It can provide the workflow layer that many organisations lack.

It can enable isolated components to be replaced without disrupting the wider operating model.

And it can provide the operational foundation for broader platform transformation when the business is ready.

This is where FundSense One fits.

Rather than forcing firms into wholesale replacement programmes, FundSense One helps asset managers modernise incrementally - preserving the technology that still delivers value while improving the way data, people and processes work together.

Modernisation Isn't About Starting Again

The assumption that legacy technology should automatically be replaced has driven countless transformation programmes. It's also led to many unnecessary ones. Most asset managers don't have a legacy system problem; they have an operational complexity problem.

The distinction matters.

Replacing the wrong application rarely removes manual work, fragmented workflows or disconnected governance. In many cases, those problems simply migrate into a newer platform.

Successful modernisation starts with understanding where value already exists, where operational friction is really being created and how significant that friction has become. Only then can firms decide whether to retain, integrate, wrap, replace or transform.

The strongest technology estates aren't necessarily those with the newest applications, they're the ones where every system has a clear purpose, every process has clear ownership, and every technology decision supports the wider operating model.

That's the real objective of modernisation.

Not replacing legacy systems.

Building an operating environment that is simpler to govern, easier to scale and better equipped for whatever comes next.