Legacy systems: signs your software is holding your business back

A legacy system is any software your business depends on but can no longer change safely, quickly or at a reasonable cost. Age is not the test. The clearest signs that it is holding the business back are these: small changes take weeks, only one person knows how it works, the real data lives in side spreadsheets, your systems do not talk to each other, and the underlying technology is no longer supported by its vendor. If you recognize three or more of these signs, the problem is no longer technical. It is a business cost, and it grows every month.

What a legacy system is (and what it is not)

People tend to picture "legacy systems" as green screens and servers in a basement, but that is not always the case. A fifteen-year-old system that is well documented, has tests and that the team changes without fear is not a problem. On the other hand, an application built three years ago, with no documentation, by a supplier that has since disappeared, may already be a legacy system.

The definition we use is a practical one: a system is legacy when the cost and risk of changing it are out of proportion to the value of the change. This happens for several reasons, often at the same time:

• the technology is no longer supported, or it is hard to find people who know it;
• the knowledge sits in the heads of one or two people;
• there are no automated tests, and every change is a gamble;
• the system has grown in layers, with patches on top of patches.

The good news is that a legacy system rarely has to be thrown away all at once. We come back to this further on.

Eight signs your legacy system is holding the business back

The examples below are typical situations in Portuguese SMEs, not specific client cases.

1. Small changes take weeks (or nobody dares to make them)

Adding a field to a customer record, changing a discount rule, creating a new report. In healthy software these are jobs of hours or a few days. In a legacy system they turn into projects, because nobody knows what else might break. The result is that the business starts adapting to the software instead of the other way round: "the system can't do that" becomes an accepted answer in meetings.

2. Only one person knows how it works

This is perhaps the most dangerous sign. There is one employee, or one outside developer, who is the only person able to fix a bug, restart a process or explain why a figure comes out the way it does. As long as that person is available, everything seems to work. When they go on holiday, change jobs or stop answering, the company discovers it depends on knowledge that was never written down.

3. The real data lives in side spreadsheets

The official system exists, but the sales team keeps its own spreadsheet with the "real" prices, the warehouse has another with corrected stock levels, and accounting reconciles everything by hand at the end of the month. When Excel becomes the source of truth, it is a sign that the system has stopped keeping up with the business. And every manual copy is a chance for errors, diverging versions and decisions made with the wrong numbers.

4. Your systems do not talk to each other

A typical situation: orders come in through the online store, are re-entered by hand into the ERP (PHC, Primavera or another), and the shipping details are copied again into the carrier's platform. Three systems, the same data typed three times. Often the ERP can actually receive data from other systems, but the older software around it cannot, and nobody wants to touch it. The cost does not appear on any invoice, but it is there in the hours lost every week and in the errors that reach the customer.

5. The underlying technology is no longer supported

All software runs on other software: operating system, database, language, libraries. When the vendor stops supporting them, security fixes stop coming. Two concrete, documented examples: Microsoft ended support for Windows Server 2012 R2 on October 10, 2023 (Microsoft Lifecycle) and for Windows 10 Home and Pro on October 14, 2025 (Microsoft Lifecycle). If a critical application only runs on one of these platforms, the company has a security problem waiting to happen, and often it cannot upgrade the platform without breaking the application.

6. Reports take days to put together

Management asks a simple question, such as "what was our margin per customer last quarter?", and the answer takes three days, because someone has to export data from two systems, match it up in a spreadsheet and fix the inconsistencies. By the time the information arrives, it is already out of date. A system that does not let you answer business questions quickly is costing you decisions, not just hours.

7. You cannot answer basic security and privacy questions

Who has access to what? Who changed this record? Can you delete all the data of a customer who asks you to? The General Data Protection Regulation (GDPR) provides, among other things, for the right to erasure of personal data (Article 17) and requires appropriate technical and organizational measures to ensure the security of processing (Article 32) (Regulation (EU) 2016/679, EUR-Lex). Many legacy systems were built before these concerns were front and center, with shared user accounts, passwords stored without protection and personal data scattered across tables nobody has mapped. If the honest answer to these questions is "we don't know", the risk is not only technical.

8. The supplier has disappeared or stopped answering

The company that built the system closed down, was bought, or simply responds more and more slowly and at a higher price. Sometimes the business paying for the software does not even hold the source code. This sign tends to appear alongside all the others and is often what finally forces action.

How to assess how serious it is

Not every sign carries the same weight. A simple way to rank them is to cross two questions:

• **Slows day-to-day work a little — **Low risk if it fails: Monitor. Record it and reassess periodically. — High risk if it fails: Protect it now: tested backups, documentation, a plan B.
• **Slows day-to-day work a lot — **Low risk if it fails: Automate or integrate the part that costs the most. — High risk if it fails: Top priority: stabilize and plan the modernization. Signs 2, 5, 7 and 8 tend to be high risk: when they fail, they fail suddenly. Signs 1, 3, 4 and 6 tend to be an ongoing cost: they do not stop the business, but they drain time and margin every month.

Four questions help put numbers on this:

• How many hours a week does the team spend copying data between systems?
• How long did the last "small" change requested to the system take?
• If the person who knows the system left tomorrow, how long would it take to replace them?
• When did someone last restore a backup to confirm that it works?

What to do next: modernize without stopping operations

The instinctive reaction to a legacy system is "let's rebuild everything". That is understandable, but it is almost always the riskiest option: a full rewrite takes months, forces you to run two systems in parallel and, at the end, has to replicate years of business rules nobody wrote down. The alternative we recommend in most cases is a phased one.

First, stabilize

Before you can improve things, you have to stop them getting worse. That means making sure there are backups that have been tested, adding monitoring where there was none, putting the source code in a repository the company controls, and documenting the minimum needed so that more than one person can operate the system.

Then, map

Which processes does the system support? What data does it hold, and where? Which other systems does it talk to, and how? This map shows which parts cause the most friction and which can stay as they are for years.

Modernize in parts

Instead of replacing everything, you replace one part at a time, starting with the one that costs the most or carries the most risk. The new system grows around the old one and takes over its functions until the old one can be switched off. In software engineering this approach is known as the "strangler fig", described by Martin Fowler (StranglerFigApplication). In practice, it can start with something as concrete as an integration that ends the manual re-entry of orders into the ERP, or with moving the data that today lives on an unpatched server to a supported database.

Data migration deserves its own attention. Old data has duplicates, fields used for different purposes over the years, and implicit rules. Migrating well means cleaning, validating and having a way to compare the old system with the new one before switching anything off.

When a full rewrite makes sense

There are cases where nothing can be saved: the technology is so obsolete that there is no safe way to run it alongside something new, or the system is small enough to be replaced in one go with controlled risk. In those cases, a rewrite is the honest answer. But it should be a conclusion reached after an assessment, not the starting point.

Common mistakes to avoid

• Waiting for the perfect assessment. An initial diagnosis of a few days is usually enough to decide the first step.
• Modernizing the technology without reviewing the process. Putting the same inefficient process on new technology only makes the problem more expensive.
• Forgetting the people who use the system. Users know the exceptions that are not written down anywhere. Involve them from the start.
• Not defining what counts as success. "A new system" is not a goal. "End the manual re-entry of orders" is.

Next step: an honest assessment of your system

If you recognized your business in several of these signs, the first step is not to get a quote for a rewrite. It is to understand what can be saved, what is at risk and where to start. That is exactly what we do in Technical Rescue: we stabilize first, then untangle piece by piece with the system running the whole time, and we tell you plainly if any part cannot be saved.

If you are also thinking about the investment, read What drives the cost of custom software (and how to control it).

Explore Technical Rescue and tell us what is broken and how urgent it is. We reply within one business day, usually with questions and a first honest opinion.