Modernizing a legacy web application without rewriting it: two real examples

I have seen that every piece of software that grows over the years runs into the same problems at some point: adding a new feature takes weeks, a small change breaks something elsewhere, screens slow down, and when the one person who knows the code leaves, nobody dares to touch it. At this point the sentence I hear most often is "Let's rewrite it from scratch." Most of the time this is the most expensive and riskiest option. In this article I explain, with examples from my own projects, how a legacy web application can be modernized without rewriting it.

Why is a rewrite risky?

When you rewrite a working system from scratch, you have to rediscover all the business rules that have accumulated over the years. Most of these rules are not written in any document; they exist only in the code. On top of that, until the new system is ready, the old system keeps living and changing. The result: a project that lasts months, goes over budget and in the end carries the same shortcomings as the old system. There are of course cases where a rewrite is right, but it should not be the first option.

How is incremental modernization done?

The path I follow is to improve the system piece by piece while keeping it running:

• Measure and examine first. Review the codebase and prioritize the problems. Which screen is slow, which module produces the most errors, which file is the place nobody wants to touch?
• Start with the most expensive problem. Solve first the problem that slows development the most or affects users the most.
• Set a common standard. Define the architecture rules, folder structure and component structure that every newly written piece will follow.
• Migrate piece by piece. Move modules to the new structure one at a time. The system keeps working at every step.
• Put the knowledge in writing. Document the rules of every migrated module so that knowledge does not depend on a single person.

Example 1: A 2,000-page banking application

At Fibabanka, the Core Banking application used by the bank's employees was migrated from a proprietary, closed interface technology to a modern React-based web architecture. The application consisted of more than 2,000 pages and more than 20 teams took part in the transformation. Instead of rewriting everything at once, we first built a shared foundation: project skeletons, a common architecture standard, and libraries of reusable components and helper functions. This way each team could migrate its own area independently. The development time of a page dropped from 1 week to under 1 day, and even backend developers with no frontend experience became able to produce pages by combining ready-made components.

Example 2: A 5-year-old no-code platform

On a no-code platform developed for 5 years at Ultia, part of the Turkcell Group, the biggest problem was performance: adding a component to the editor meant a wait of over a minute. Instead of rewriting the platform, we first found and fixed the root cause of this bottleneck, then improved the developer experience and split oversized files into a modular structure with a planned refactor program. While the platform kept running, the team started developing faster.

When is a rewrite really needed?

When the technology in use is no longer supported and carries a security risk, when the business model has changed completely, or when the system is so small that rewriting is cheaper than migrating. Even in these cases, bringing the new system online module by module instead of shutting down the old system all at once reduces risk.

Where to start?

The first step is a short code review. In as little as a week, the state of the codebase, the most critical problems and a realistic improvement plan emerge. This plan lets you answer the question "should we rewrite it?" with data rather than guesswork.

The hidden gain of modernization: team speed

The most overlooked benefit of legacy modernization is the team's development speed. Hot reload time dropping from minutes to seconds, shared components being ready, and rules being written down make every new feature cheaper. The return on the investment is usually seen in the first few months, in the delivery time of new features. That is why modernization should be thought of not as a cost item but as an infrastructure investment that speeds up all later development. When planned properly, users experience no downtime, and the team feels the difference from the first weeks.