Every company with a successful product eventually faces the same reckoning: the system that got you to this point is now the system holding you back.
We've modernised dozens of legacy Java systems over the past two decades. Here are the five warning signs we see most often — usually in the six months before something truly breaks.
1. Your deploy cycle is measured in weeks, not hours
If shipping a single feature requires a two-week release cycle with manual testing, environment coordination, and a deployment window that everyone dreads — your system is telling you something. Modern engineering teams deploy multiple times per day. If yours can't, the architecture is the bottleneck.
2. Nobody wants to touch "that" module
Every legacy system has one. The module that's been written and rewritten by five different developers over eight years, with no tests, no documentation, and business logic that only one person (who left last year) truly understood. When your team routes around core functionality because they're afraid of breaking it, the technical debt has become a business risk.
3. Your Java version is more than two major releases behind
Still on Java 8? Java 11? You're missing years of security patches, performance improvements, and language features that make your developers more productive. More critically, your dependency ecosystem is shrinking — libraries are dropping support, and finding developers who want to work on legacy Java is getting harder and more expensive every quarter.
4. Performance issues are addressed with hardware, not architecture
When the response time creeps up and the solution is "add another server" or "increase the memory," you're treating symptoms, not the disease. Architectural inefficiencies compound — and eventually, no amount of hardware can compensate for N+1 queries, synchronous blocking calls, and monolithic deployment constraints.
5. New feature estimates keep growing
If the same category of feature that took two weeks three years ago now takes six weeks, your codebase has accumulated enough complexity that every new addition requires navigating a maze of dependencies, workarounds, and fragile integrations. This is the most expensive warning sign — it's silently multiplying the cost of every feature your product team requests.
The good news
Legacy modernisation doesn't have to mean a two-year rewrite. We use incremental approaches — strangler fig patterns, careful service extraction, and phased database migrations — that let you modernise while keeping the business running. The system that got you here deserves a thoughtful evolution, not a reckless replacement.