Rescue or rewrite? How I decide what to do with an old app

"Should we just rewrite it?" It is one of the first questions I get when someone sends me an app that keeps breaking. The code is old, the developer is gone, and every fix seems to cause two new bugs. Starting fresh sounds clean.

Sometimes it is the right call. More often it is not, or not yet. This is how I decide.

What a rewrite really costs

The old app is messy, but it also holds years of decisions. Every odd rule in it is there because a real user or a real customer needed it once. Most of those rules are not written down anywhere else.

A rewrite has to find all of them again. While it does, the old app still has to run, still has to be fixed, and still earns the money. For a while you pay for two apps and get the value of one.

That does not mean never rewrite. It means a rewrite has to earn its place.

First, make it safe to touch

I do not decide on day one. Before I can say anything useful, the app has to be in a state where changing it is not a gamble:

• I can get into everything: the repo, the hosting, the database, the domain.
• There is a backup, and I have restored it once.
• Errors are logged somewhere I can read them.
• A deploy can be rolled back.

This part is the same whatever we decide later. Without it, a fix and a rewrite are both risky. I wrote about these first days in more detail in my first 10 days on a rescue.

Then, look at where the pain comes from

Once I can see the errors and reproduce the loudest bugs, a pattern usually shows up. The question is whether the pain is spread everywhere or sits in a few places.

If most of the trouble comes from a handful of areas, a rescue wins. Fix those areas, add tests around them, and the rest of the app can stay as it is.

If the trouble is everywhere, because the foundation itself is the problem, a rewrite starts to make sense.

Signs a rescue is enough

• The app does what the business needs. The complaints are about bugs and speed, not missing features.
• The language and framework are old but still supported, or can be upgraded step by step.
• Most bugs live in a few screens or a few jobs.
• The data model makes sense, even if the code around it does not.

Signs a rewrite is worth it

• The platform it runs on is no longer supported and cannot be upgraded in steps.
• The business has changed so much that the app's core idea no longer fits.
• Every change, even a small one, touches the whole codebase.
• Nobody can run it outside the one server it lives on, and that server cannot be rebuilt.

Usually, the answer is both, in order

When a rewrite is right, I still rescue first. A stable old app buys time to rebuild without pressure. Then the new parts can replace the old ones piece by piece, a module or a screen at a time, while users keep working.

If you are weighing this up, these are the questions I would ask you:

If you are not sure about half of them, that is normal. Finding out is the first part of the work.

If yours is keeping you up

Tell me what the app does and what keeps breaking. Describe it on the scope page or get in touch, and I will tell you which way I would start, and why.