Legacy in App Development — What It Is, Risks and Strategies

What Is Legacy in App Development

Legacy — code or a system that continues to run in production but no longer meets modern quality standards. Legacy can be written in an outdated language (e.g., Objective-C instead of Swift), use unsupported libraries, or architectural patterns long considered anti-patterns.

The key characteristic of legacy is the absence of tests. By Michael Feathers (2004)’s definition, legacy code is code without tests. If you can’t safely change behavior, the system is in legacy status regardless of age. Fresh code without unit tests is legacy from day one.

Legacy is not necessarily bad. A well-designed system in Java 8 can be more reliable and understandable than chaotic Kotlin code with coroutines. Code age is not an indicator of quality — what matters is how easily the system can be changed and extended.

Why Legacy Code Is Normal

Every successful system becomes legacy over time. This is a natural process: technologies evolve faster than code can be rewritten. An app written 5 years ago in Swift 2 is legacy today, even though it was modern at the time of creation.

The business value of legacy is often underestimated. The system works reliably, processes transactions, stores data — rewriting carries risks. According to Standish Group (2024), 35% of full rewrite projects end in failure. It’s economically justified not to get rid of legacy, but to learn to work with it.

The best strategies are gradual migration, encapsulating old code behind new interfaces, and automated testing. Legacy only becomes a problem when it stops being changeable at a predictable cost.

Key Signs of a Legacy System

Lack of automated tests — the main indicator. If after changing a single line a developer cannot run tests and confirm nothing broke — you’re dealing with legacy. An additional sign: the deployment process takes hours and requires manual steps.

Documentation doesn’t match the code — another marker. Architectural diagrams are outdated, comments describe behavior that has already changed. Time-to-ramp-up for a new developer exceeds a month — a sign of high complexity and low maintainability.

Additional signs: monolithic architecture without clear boundaries, manual testing as the primary verification method, long CI pipeline (over 30 minutes), use of libraries without current versions, and inability to update dependencies without breaking related modules.

The “fragile code” phenomenon — a change in one place breaks three others. This results from tight coupling, where modules know too much about each other. The higher the coupling, the faster the system transitions into the legacy category.

Risks of Working with Outdated Code

Reduced speed — the main risk. Adding a simple feature takes hours of studying code and days of testing. According to Stripe (2024), developers spend 33% of their time overcoming technical debt, which is directly related to the presence of legacy modules in the project.

Expertise leakage — original code authors leave the company, and documentation is incomplete. New developers are afraid to touch unfamiliar modules, leading to the “frozen code” effect: the module doesn’t evolve but continues to work. The bus factor of such systems is critically low.

Security — outdated libraries contain known vulnerabilities. Using OpenSSL 1.0.2 or outdated versions of Jackson in Java projects is a direct path to security incidents that can cost the business reputation and customers.

Team demotivation — working with legacy without a strategy for improvement reduces developer satisfaction. The team stops being proud of the product, staff turnover increases, which further slows down system development.

Legacy Refactoring Strategies

Characterization tests — the first step before any change to legacy code. Run the code on known input data and record the expected output. These tests capture current behavior as a specification. Golden master testing is a variant where output is compared against a reference file.

Seam analysis — finding points where coupling can be broken without changing behavior. Michael Feathers identifies several types of seams: preprocessor seam, object seam, link seam. Object seam is the most common: replacing a real object with a test stub through an interface.

Sprout method and Sprout class — techniques for adding new code alongside old code rather than inside it. Instead of modifying an existing method, create a new method with the desired logic and call it from the old one. This minimizes the risk of breaking working code.

Example: Adding Logging to Legacy

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 lines of legacy code that should not be touched
        logPayment(payment) // sprout method
    }
    def logPayment(payment) {
        // new code added alongside legacy
    }
}

Migration to a Modern Tech Stack

Strangler Fig pattern — the recommended approach for legacy migration. A new module is created in parallel, traffic is gradually switched from old to new. The old module “dies” naturally when it stops receiving requests. The pattern minimizes risks and allows rollback if problems arise.

Branch by Abstraction — a technique where an abstraction is created over the old and new implementations. Client code switches to the abstraction, and the old implementation is gradually replaced. Example: replacing the networking layer from AFNetworking to Alamofire through a unified NetworkService protocol.

Phased migration — breaking the transition into small steps: encapsulate the old module → write tests → create a new module → run in parallel → remove the old module. Each step ends with a stable system state, allowing deployment at any moment.