Should You Repair or Replace a Legacy Internal App?

Most companies have at least one internal system that everyone depends on and nobody wants to touch. It might be an old web app, a desktop tool, or a spreadsheet that grew macros and became a system without anyone deciding it should. At some point the question comes up: fix what is there, or replace it?

There is no universal answer. Modernization is not always the right call, and neither is patching. This guide sets out the signs that point each way, what to write down before deciding, and how a replacement can happen in stages instead of one risky weekend.

Signs that repair is enough

Repairing, meaning targeted fixes, performance work, or a few new features on the existing system, is usually the cheaper path when:

• The data model still matches how you work. The records, fields and relationships in the system reflect your current process, even if the screens are dated.
• The problems are specific. Slow reports, one unreliable integration, a confusing screen. These can be fixed one at a time.
• Someone understands the code. A developer, current or available, can read it and change it without breaking unrelated features.
• The platform is still supported. The language, framework, database and hosting still receive security updates.
• Changes are slow but predictable. Small changes take longer than you would like, but they land without surprises.

If most of these are true, a focused repair plan will usually deliver more value per dollar than a rewrite.

Signs that replacement is cheaper over time

Replacement starts to make sense when the cost of keeping the system alive keeps rising:

• Every change breaks something else. Small requests become multi-week efforts because nobody can predict the side effects.
• Nobody can explain how it works. The original developers are gone, documentation is missing, and knowledge lives in a few people's heads.
• The platform is out of support. Security patches have stopped for the framework, runtime or database.
• The process has outgrown the data model. New roles, products or approval steps are being squeezed into fields that were never meant for them.
• Workarounds have become the process. People export to spreadsheets, re-type data or keep side lists because the system cannot do what they need.

When several of these are true, repairs tend to slow down the decline without reversing it.

What to inventory before deciding

Before choosing either path, write down what the current system actually does. This inventory is useful whichever way you go, and it is the first thing any credible vendor will ask for.

Workflows. Every task people perform in the system, from start to finish. Include the unofficial ones — the export someone runs every Friday, the spreadsheet that fixes a report the system gets wrong.

Users and permissions. Who uses the system, what each group can see and change, and where those rules are enforced. Note any permissions that exist only by convention ("only Maria edits prices").

Data. The main tables or files, roughly how many records, how clean they are, and which records must survive a replacement.

Connections. Every system that reads from or writes to this one: accounting, CRM, email, file drops, reports other teams depend on.

Pain points. What people actually complain about, in their words. This list separates must-fix problems from nice-to-haves.

How a staged replacement works

Replacing a system does not have to mean switching everything off on a Friday and hoping on Monday. A staged approach limits the blast radius:

1. Pick a first migration boundary. Move one workflow, one team or one product line first. The rest keep using the old system for now.
2. Build the replacement for that boundary. Include the permissions, the data it needs and the connections that workflow depends on.
3. Run trial imports. Import real data into the new system and check it with the people who know it best. Fix the mapping, then repeat.
4. Write a rollback plan. Decide in advance what failure looks like and how you would return to the old process for that boundary.
5. Switch the first boundary. Watch it closely, and fix what real use reveals.
6. Repeat, then retire. Move the next boundary, and switch the old system off only when nothing depends on it.

The cost of this approach is running two systems for a while. The benefit is that no single step can take the whole business down.

Questions to ask any vendor

Whether you are hiring someone to repair or to replace, their answers to these questions tell you a lot:

• How will you learn what the current system does, including the workarounds?
• What would you move first, and why?
• How will you check that migrated data is correct before we switch?
• What is the rollback plan if the switch goes wrong?
• How are permissions rebuilt and tested in the new system?
• What documentation will we have at the end, and who can maintain it?

A vendor who recommends a full rewrite before asking about your workflows, or who cannot describe a rollback plan, is guessing.

Next step

If you have an internal system that is getting harder to change, start with the inventory above. It is worth doing even if you decide to keep the system. When you are ready to talk it through, see how we approach custom web applications, or tell us about the system and we will help you decide whether to repair or replace it.