How to identify and assess a legacy application

A legacy application is usually not simply “old software”, but a business-critical application that is still needed from a functional perspective, yet is running up against technical or organisational limits. Typical examples include Access solutions, older desktop applications, or web applications that have evolved over many years. For decision-makers, what matters is less how old an application looks and more whether it is slowing operations down, increasing risk, or making change unnecessarily expensive.

This article explains how to recognise a legacy application, how to assess its condition realistically, and which next steps make sense. If you would like to turn this into a concrete project, a rough cost estimate, a structured project brief or an initial no-obligation consultation can help with an initial assessment.

What really makes an application legacy

A legacy application is an existing line-of-business application that is still used day to day, but no longer fits current requirements well from a technological, functional or operational point of view. So the key point is not simply that software has been in use for a long time, but that it makes change more difficult.

Age alone is not enough as a criterion. Even a comparatively young application can have legacy characteristics if it is difficult to maintain, poorly documented, or heavily dependent on the knowledge of individual people.

It is important to distinguish between functional value and technical condition. An application may be indispensable for core processes while at the same time being built in a way that makes changes risky or time-consuming.

Typical forms include, for example:

• Access databases
• older desktop programs
• monolithic web applications
• bespoke systems that have grown over time and include many special cases

A monolith is an application in which many functions are tightly coupled within one large system, so changes can easily affect one another.

Legacy therefore does not automatically mean “replace it”. Some systems can be stabilised, extended selectively or modernised step by step, for example through new interfaces, database work or suitable services for web, apps and operations.

For decision-makers, what ultimately matters is the impact the application has on processes, risk, further development and future viability. Related topics such as identities and single sign-on in your own application context often play a part as well. You can also get an idea of what such projects can look like in practice from selected completed projects.

How to recognise a legacy application in day-to-day work

Whether an application is legacy usually becomes apparent in day-to-day work not through the technology first, but through recurring friction. For decision-makers, observable signals are often more meaningful than technical jargon.

One common sign is that even small changes become disproportionately time-consuming. An additional report, a new field or an adjustment to a process suddenly requires extensive coordination, can only be planned with uncertainty, or causes errors in unexpected places. In that case, the existing structure often no longer fits new requirements particularly well.

Dependence on individual knowledge is just as critical. If only a few people still understand how the application works internally, that creates an organisational risk. Knowledge then sits more in people’s heads, emails or old notes than in clear, comprehensible documentation.

Another warning sign is limited connectivity. Interfaces to other systems are incomplete, have grown historically, or can only be used with considerable effort. An interface is a defined connection through which applications exchange data or trigger functions. If every integration turns into a special project, it slows down not only IT but often business processes as well.

Operations also provide clear clues:

• incidents are difficult to isolate
• updates are considered risky
• recurring manual interventions are part of day-to-day work
• the same errors reappear in different places

Access and security issues are another factor. If user management, roles or sign-in no longer fit the current environment, identities should be reviewed afresh. Single sign-on means that once users have signed in, they can be recognised across multiple applications instead of needing separate credentials for each one.

How to assess a legacy application properly

For a sound assessment, it helps to divide the evaluation of a legacy application into four perspectives: business function, technology, operations and organisation. This avoids the discussion revolving too early around isolated faults or preferred solutions.

From a functional perspective, you should clarify which processes the application is actually supporting today. Not everything present in the software is still relevant. It is important to distinguish between business-critical processes, useful functions and elements that are only still running for historical reasons.

Technically, the main issue is maintainability. This means examining how understandable the structure is, how usable the data model and interfaces are, and how safely changes can be implemented. The data model describes how information is structured, linked and stored within the application. If this foundation is unclear or inconsistent, even a small change quickly becomes a risk.

From an operational point of view, what matters is how stable the application is and how well incidents can be isolated. It is equally relevant how clearly deployment and updates are organised. CI/CD refers to a structured process for building, testing and deploying changes in a traceable way. If this kind of framework is missing, dependency on manual one-off steps often increases.

The organisational perspective is easily underestimated. So also check how strongly the system depends on individual people, specific devices or long-established special processes. This is often where risks arise that remain invisible in day-to-day business for a long time.

It is also sensible not to document weaknesses only. Record what is already working well too:

• stable core processes
• proven business logic
• valuable data sets
• clearly defined user groups

Only by looking at weaknesses and strengths together do you get a realistic picture.

Replace, modernise or extend selectively?

After the assessment comes the practical question: which path suits the legacy application? In most cases, three basic options can be distinguished:

• complete replacement
• step-by-step modernisation
• targeted extension of the existing application

Complete replacement makes sense above all when business requirements and the technical foundation have drifted so far apart that continued development is no longer sustainable. This is often the case when processes have changed significantly, but the application is still based on old assumptions and can now only be adapted with considerable effort.

Step-by-step modernisation is often the more realistic route. Existing functions remain usable at first, while individual parts are renewed gradually, for example interfaces, data access or integrations. This makes the risk easier to manage because not everything has to be changed at once.

Then there is targeted extension. Some legacy applications remain largely intact at their core but are given new web interfaces, additional reporting, interfaces or mobile usage options. A web application runs in the browser and can be deployed centrally, without having to be installed individually on every workstation.

Database strategy is also important here. Valuable data sets often need to be migrated, cleaned up or restructured. A database is the structured storage location for the information an application processes.

Where it fits the target architecture, modern bespoke software is now often implemented using current .NET, SQL databases and cloud components.

How a viable modernisation path emerges

A viable modernisation path rarely emerges when the initiative is treated purely as an IT topic. It is more effective to align business stakeholders, operations and responsible decision-makers early on around goals, risks and a sensible sequence.

In practice, the path is usually most workable if you proceed step by step:

• capture the current state
• define the target picture
• compare options for action
• prioritise risks
• derive an approach that can actually be implemented

It is also important to consider quality assurance from the outset. Tests help ensure that existing core functions can still be checked reliably even when changes are made to the application. Automated tests check important processes in a way that makes repeatable verification possible without manual individual testing.

Integrations and identities should likewise be taken into account early on so that the modernised or new solution does not become a special case all over again later. The cost calculator helps with an initial assessment of the project scope.