When Does a System Become "Legacy"?
A system becomes legacy not when it's old, but when it costs more to maintain than to replace, actively limits your ability to ship new features, or creates unacceptable business risk through security vulnerabilities or reliability failures. Age is irrelevant — a 10-year-old system on modern architecture can be perfectly maintainable; a 3-year-old system built on the wrong foundations may already be legacy. The seven signs below give you a diagnostic framework to assess where your system sits on that spectrum.
According to McKinsey Digital, legacy technology costs consume 70–80% of IT budgets at large organisations, leaving only 20–30% for innovation. Modernisation is not a technical project — it's a business imperative.
Sign 1: Maintenance Consumes More Than 60% of Engineering Capacity
The first and most concrete sign: track how your engineering team spends its time. If more than 60% of engineering effort goes to keeping the lights on — bug fixes, performance patches, dependency updates, environment issues, data corrections — rather than building new capability, you have a legacy problem.
How to measure it: ask your engineering team to log their time in two categories for two weeks: maintenance/operational vs new feature development. The ratio is almost always worse than leaders expect.
What it means: The system is fighting you. Every feature takes disproportionate effort because the foundation is fragile. The codebase has so many interdependencies that changes in one place break things in unexpected places. You're spending your engineering budget on the past rather than the future.
What to do: Prioritise identifying the highest-maintenance subsystems. Modernisation doesn't have to be all-or-nothing — strangling out the highest-burden components first can recover significant capacity while the rest of the system is addressed incrementally.
Sign 2: You Can't Hire Developers Who Want to Work on It
This is the talent market sending you a signal. Technology choices made 10–15 years ago — COBOL, VBScript, Classic ASP, early-generation Java EE frameworks, Perl — have shrinking talent pools. The developers still working in these stacks are largely those nearing retirement, and they command significant salary premiums precisely because of their scarcity.
More subtly: even if the technology has a large pool (e.g., Java), if your system uses outdated patterns (EJB-heavy monolith, XML-configuration Spring 2.x, proprietary frameworks), talented developers will decline opportunities to work on it. Engineers care about their career development — spending years maintaining an unfashionable codebase is a career cost they weigh when evaluating job offers.
Warning signs:
- Your job postings mention technology that candidates haven't used in their last 2 positions
- Interview conversion rates are significantly below market (experienced engineers are declining offers)
- Your most experienced engineers are the only ones who truly understand the system
- Junior developers are requesting transfers off the project within 12 months
Sign 3: Security Vulnerabilities You Can't Patch
A legacy system becomes a security liability when its dependencies are no longer maintained and cannot be updated without breaking the application. This situation is more common than organisations acknowledge:
- Running an end-of-life version of a language runtime (Python 2, PHP 5, Java 8 under extended support) that can no longer receive security patches
- Third-party libraries that haven't been updated in 3+ years and have known CVEs
- Framework versions that can't be upgraded because the application is too tightly coupled to deprecated APIs
- Operating systems approaching end-of-extended-support (Windows Server 2012, CentOS 7)
The regulatory and liability implications in Europe are significant. Under GDPR, organisations have a duty to implement appropriate technical security measures. Running knowingly vulnerable software and suffering a data breach is difficult to defend to a supervisory authority. NIS2 — applicable to more organisations from 2025 — adds additional security obligations.
What to do: Commission a technical security assessment to understand your specific exposure. Prioritise systems that process personal data for immediate modernisation or isolation.
Sign 4: Integration With Modern Tools Is Increasingly Painful
Business requirements continuously evolve: new payment providers, new CRM systems, new analytics tools, new B2B partner APIs. If integrating each new third-party system requires weeks of effort and custom adapters, or if the core system has no API at all (direct database access, SFTP file exchange, or flat file integration are common legacy patterns), you're paying an integration tax on every business initiative.
Modern integration should take days for standard APIs, not months. If your engineers regularly say "we can't integrate that because of how our core system works," that's a concrete sign the architecture is limiting the business.
Common Legacy Integration Anti-Patterns
- Point-to-point integrations: every new system connected directly to every other
- Shared database integration: external systems reading directly from your application database
- Batch file exchange: data movement via overnight SFTP transfers rather than real-time events
- No API layer: business logic only accessible via the UI, forcing screen-scraping workarounds
Sign 5: Performance Degradation Under Normal Growth
A system that performed acceptably at 10,000 users but struggles at 100,000 users has a scalability problem that modernisation can address. Common patterns:
- Database queries that run fine with small data volumes but slow to seconds as the dataset grows
- Single-threaded processing that can't take advantage of modern multi-core hardware
- Session-based architectures that don't scale horizontally without sticky sessions
- Monolithic architectures where scaling the highest-load component requires scaling the entire application
The business impact: customer-facing performance problems drive churn. Research from Akamai consistently shows that a 100ms increase in page load time correlates with a 7% reduction in conversion rates. For e-commerce and SaaS products, this is a direct revenue measurement.
Sign 6: Regulatory Compliance Gaps You Can't Close
Regulations evolve. Systems designed before GDPR (2018), PSD2 (2019), NIS2 (2025), or sector-specific regulations may have structural gaps that are expensive or impossible to address without modernisation:
- No audit logging of data access (required by GDPR for personal data processing)
- No data export capability (right to data portability)
- No data deletion mechanism (right to erasure)
- Passwords stored without proper hashing (BCrypt or Argon2)
- No consent management or audit trail
- Session management vulnerabilities (OWASP Top 10 items that can't be patched in legacy frameworks)
In the Netherlands and Germany specifically, supervisory authorities (AP and BfDI) have been increasingly active in enforcement. GDPR fines of 2–4% of global annual revenue make this a board-level business risk.
Sign 7: Competitors Are Shipping Features You Can't
The ultimate business measure: if a competitor with a modern technology stack is consistently shipping features that your customers want — and you can't because your system won't support the required data model, real-time processing, or API architecture — you're losing the technology race that determines market position.
This is often the trigger that finally moves modernisation from the "too big, too expensive" category to the "survival" category. By that point, the modernisation scope is usually larger and the urgency higher than it would have been had the decision been made earlier.
What to Do: A Modernisation Decision Framework
If you recognise 2–3 of these signs, it's time to plan. If you recognise 4+, it's urgent.
Start With Assessment
Before spending a euro on modernisation work, invest in understanding the system: its architecture, its technical debt inventory, its critical paths, and its risk profile. A well-scoped assessment takes 2–4 weeks and gives you the data to make informed investment decisions. See our legacy modernisation service for details on how we structure this.
Choose Your Approach
- Strangle Fig pattern — Build the replacement system alongside the legacy system, routing traffic incrementally. Lowest risk, longest timeline.
- Component-by-component extraction — Identify and extract high-value, high-pain components first. Monolith to microservices is a common variant.
- Big Bang rewrite — Almost always the wrong choice. High risk, long time-to-value, and you lose the lessons learned building the original system.
Fund It as a Business Investment
Modernisation should be funded as a strategic business investment, not buried in the IT maintenance budget. Build the ROI case using the maintenance cost recovery, risk reduction, and competitive impact metrics surfaced by your assessment.
If you're unsure which signs apply to your system, our technical assessment gives you a clear picture within 2–4 weeks. And if you've identified the problem and want to understand the cost of delay, read our guide on the true cost of technical debt.
