Ten risk factors that make old business systems dangerous, the daily hassles they cause, a simple likelihood-and-impact heat map, and the strangler-fig pattern for replacing a legacy system one capability at a time.
Author
Anichur Rahaman
Legacy software rarely fails loudly. It fails slowly. A report takes a little longer every month. A new payment method needs "a few weeks" of work. The one developer who understands the stock module goes on holiday, and the whole team waits for them to come back.
Owners usually feel these symptoms long before anyone names the cause. As an architect, my job when I review an older business system is to turn that vague discomfort into a list of specific risks, score them, and propose a way out that does not stop the business. This article shares that method.
You will find ten risk factors to check, the everyday hassles each one causes, a simple scoring heat map, and a modernisation approach — the strangler-fig pattern — that replaces an old system one capability at a time instead of betting everything on a big rewrite.
Legacy is not about age. A five-year-old system can be modern if it is tested, documented and running on supported software. A two-year-old system can be legacy if nobody dares to change it. A practical definition:
Legacy software is any system the business depends on but cannot change safely, quickly or affordably.
By that definition, the question is not "how old is it?" but "how risky is it to change, and how risky is it to leave alone?" Both have a cost.
When the language version or framework reaches end of life, security patches stop. Every month after that, the gap between known vulnerabilities and your defences widens. Upgrading later is also harder, because libraries move on and stop supporting your version.
Daily hassle: "We can't add that payment gateway; its library needs a newer PHP."
One developer or one contractor knows how the system works. Nothing is written down, and knowledge leaves when they do. This is often the highest-impact risk, and the one owners notice last.
Daily hassle: releases, fixes and even simple data corrections wait for one person's calendar.
Without tests, every change is a gamble, so teams change as little as possible. Fixes are patched around problems instead of through them, and the code becomes harder to change each year.
Daily hassle: "We fixed the invoice rounding, and now the discount report is wrong."
Hundreds of tables, read and written by every part of the application, sometimes by outside scripts too. A change to one column can break a screen nobody remembers exists.
Daily hassle: a simple field change becomes a week of searching for side effects.
Passwords stored with outdated hashing, API keys committed to the code, admin pages without two-factor sign-in, error pages that print database details, missing rate limits on login. Each one is small; together they are an open door.
Daily hassle: nobody wants to answer the security questionnaire from a large customer.
Customer data in the shop, the CRM and a spreadsheet; stock in the system and in the warehouse manager's notebook. When numbers disagree, people stop trusting all of them.
Daily hassle: meetings spent arguing about which report is correct.
Nightly CSV files over FTP, scripts that scrape a supplier's website, integrations that silently stop when a password expires. They work until they don't — and nobody notices for days.
Daily hassle: "The courier statuses haven't updated since Tuesday."
Queries that load one record at a time inside a loop, no caching, reports that scan whole tables. Fine with a thousand orders, painful with a million.
Daily hassle: month-end reports run overnight, and the store slows down while they do.
No record of who changed a price, a salary or a stock count. No way to export or delete a customer's personal data on request. Consent not recorded. Data protection laws in many regions make these legal obligations, not nice-to-haves.
Daily hassle: an auditor's question that takes a week to answer.
A closed system whose vendor controls your data export, raises prices at renewal or discontinues the product. Sometimes the contract itself is the risk.
Daily hassle: "We'd like to leave, but we can't get our data out in a usable form."
You do not need a consultant to start. Gather the people who use and maintain the system, and score each risk from 1 to 5 on two axes:
Multiply the two. Anything scoring 15 or more is a priority this quarter. Anything between 8 and 14 belongs on the roadmap. Below 8, monitor it. The heat map above is simply this table drawn as a picture, and it is the most effective slide I know for getting a board to fund modernisation.
| Risk | Likelihood (1–5) | Impact (1–5) | Score | Action |
|---|---|---|---|---|
| Unsupported runtime | 5 | 5 | 25 | This quarter |
| Key-person dependency | 4 | 5 | 20 | This quarter |
| Security debt | 4 | 5 | 20 | This quarter |
| No automated tests | 4 | 4 | 16 | This quarter |
| Fragile integrations | 3 | 3 | 9 | Roadmap |
| Vendor lock-in | 2 | 4 | 8 | Roadmap |
The scores above are an example, not a benchmark. Your own workshop will produce different ones, and the conversation is half the value.
Once the risks are visible, the tempting answer is "let's rebuild it properly". Full rewrites fail far more often than they succeed, for predictable reasons:
The strangler fig is a plant that grows around a host tree until it can stand on its own. In software, the new system grows around the old one, taking over one capability at a time, until the old core can be switched off.
Place a routing layer — an API gateway or a thin proxy — in front of the old system. At first it sends 100% of traffic to the legacy core. In parallel:
Choose a capability that is valuable and well bounded: catalog and stock, or orders. Build or adopt the new module, and route that capability to it.
When the last capability has moved, archive historical data to read-only storage, switch off the remaining legacy screens and delete the old code. Keep the data; lose the risk.
Not every part of a legacy system deserves the same treatment. Three questions decide the path for each capability:
A few lessons that come from experience rather than textbooks:
StoreConsole was built as a set of independent modules — catalog, inventory, orders, delivery, accounting, HR, payroll, CRM and more — that communicate only through events. That makes it a natural target for the "replace" path: you can adopt one module behind your facade, feed it from your legacy outbox, and move the next one when the first is stable. Every module keeps an activity log, role-based permissions and two-factor sign-in, which closes several of the risks above on day one. The short tour below shows roles, two-factor sign-in and the audit trail.
Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.
About the Author
Anichur Rahaman
Continue Reading
