Modernizing legacy applications without stopping the business

Almost every business that has run for a few years has at least one application that "works, but nobody dares to touch." The code is old, the documentation is missing, and the people who wrote it are long gone. The system still brings in revenue, so it's tempting to leave it alone — until the day a small bug blocks invoicing or a new requirement becomes impossible to implement.

The good news is that modernization doesn't have to mean stopping everything and rewriting from scratch. In this article we show how we at CraftWork approach a legacy modernization project: incrementally, with controlled risk, and with the business running the entire time.

Why a legacy system becomes a liability over time

"Legacy" doesn't just mean "old." It means code that is increasingly hard and expensive to change safely. The warning signs appear gradually:

• The cost of change rises: an edit that once took a day now needs two weeks and endless manual testing.
• Security risk piles up: frameworks and libraries that no longer receive updates become an entry point for attacks.
• Hiring gets hard: few developers want to work with dead technologies, and the ones who know the system become a single point of failure.
• Integrating with new tools (payments, AI, cloud services) is blocked by an architecture never designed for it.

The "big-bang" rewrite trap

The instinctive reaction is seductive: "let's rewrite everything clean and modern, once and for all." In practice, a from-scratch rewrite is one of the riskiest technical decisions you can make. While the team builds the new system in parallel, the old one keeps evolving — bugs to fix, customer requests, business rules written nowhere but encoded in the code. The new version chases a moving target and is often delivered months or years late, right when budget and patience have run out.

Strangler-fig: replacing it piece by piece

The alternative we prefer is called "strangler-fig," after the plant that grows around a tree and gradually replaces it. The idea: put a barrier (a router, a proxy, an API gateway) in front of the old system and start redirecting traffic, function by function, to new modules. The legacy system stays in production and keeps serving everything you haven't migrated yet, and the customer notices no interruption.

To choose what to modernize first, look for the modules that sit at the intersection of high business value and high maintenance pain. A simple prioritization exercise:

• Start with a small but real slice — a full flow, not an isolated function — so you validate the approach end to end.
• Prioritize areas that change often or block new business requests; that's where modernization pays off immediately.
• Leave the stable modules that "just work" and haven't been touched in months for later — don't burn time there.
• Measure progress concretely: the share of traffic served by new code, the average lead time for a change, the number of incidents.

Our rule: no modernization step should take longer than a few weeks to reach a version shippable to production. If a step becomes a project of its own, you've split it wrong.

Protect the data and involve the team

Data is the most delicate part of any migration — you can re-release code, but lost data doesn't come back. Run the old and new systems in parallel for a while, keep them in sync, and compare results before switching over for good. Take verified backups (not just existing ones), migrate in small reversible batches, and keep a clear rollback path at every step. Just as important are the people: involve the team that knows the unwritten business rules, document as you discover, and turn modernization into a chance to share knowledge rather than concentrate it in one person again.

When a full rewrite really is justified

Incremental modernization is not a dogma. Sometimes gradual refactoring is the right answer; sometimes a targeted rewrite is justified — for example when the core technology has lost support and available talent, when the fundamental data model can no longer sustain the direction of the business, or when the system is small and isolated and rewriting it is a matter of days, not years. The key is to decide deliberately, based on cost and risk, not on enthusiasm for new technology. Most of the time a mix — refactor where you can, replace where you must — beats either extreme.

Conclusion

Legacy modernization doesn't have to be a leap into the dark. With the strangler-fig pattern, clear priorities, and care for your data, you can bring a system into the present without stopping the business for a single day. If you have an application that "nobody touches anymore," get in touch — we'll run a quick assessment together and show you where to start with the least risk and the biggest gain.