“Let’s rewrite it” can be a reasonable response to the limitations of an ageing application. The problem starts when it replaces diagnosis. Changing frameworks does not decide who owns the decisions, how business processes work, or why every change touches a dozen modules. Before planning a rewrite, identify the cost you want to remove.
Start with the problem, then consider the technology
Imagine an admin panel where adding a form field takes several days. The cause might be a model shared across many screens, a dependency on an undocumented API, or nobody knowing the validation rules. Each requires a different intervention. React alone will not resolve any of them.
Ask specific questions: which changes do we make most often, where does the time go, and which constraints block product development? Trace a few recent tasks from request to release. “The code is old” describes its age. “Changing validation requires updating five separate implementations” gives you something to investigate.
Compare three options instead of committing to one big plan
The first option is improving the current application: removing duplication, clarifying module boundaries, updating dependencies, and protecting important user flows. The second is replacing selected features incrementally. The third is building a new application and switching users over. Evaluate all three against the same problem and time horizon.
Include the time to the first useful improvement, the cost of maintaining two implementations, rarely used behaviours that must be reproduced, data migration, and rollback. Account for business changes that will arrive while the replacement is being built. The existing product rarely stands still during the project.
When to postpone a full rewrite
Be cautious when the team cannot yet describe the current behaviour, nobody owns product decisions, or the scope of the new version keeps growing. A plan that delivers its first value only after the whole system has been rebuilt is also risky. It leaves little room to validate assumptions early.
If the biggest problems are concentrated in two screens, replacing the entire application may be disproportionate. Conversely, a small product with well-understood behaviour may be a good candidate for a full replacement. Codebase size, dependencies, and cutover risk matter more than loyalty to one strategy.
When a replacement has a strong case
A rewrite may be justified if dependencies can no longer meet the required security standard, the product model changes fundamentally, or working around a constraint would cost more than replacing the system. Verify those claims. “It cannot be done” should describe an investigated limit, not a lack of ideas at the first meeting.
A good plan states what the team will deliberately stop supporting. Reproducing every historical detail while redesigning the entire UX makes scope difficult to estimate. Behaviour changes need an owner and explicit acceptance rather than entering the new version by accident.
Run a small experiment before making a large commitment
Instead of estimating the whole replacement immediately, choose one representative feature. Use it to test the integration, the release process, and the actual cost of keeping both implementations running. Picking only the easiest screen tells you little about the harder dependencies.
Before starting, record the evaluation criteria: what should become easier, how you will check it, and what would make you stop. After the experiment, accept every possible outcome, including a decision to keep the current approach.
A rewrite is worth pursuing when you can explain why replacement is the best way to solve a specific problem. The promise of a more pleasant development experience in a new stack is not enough to commit the whole product.