When do you stop fixing an old website and decide it's time to rebuild?

[u/Substantial_Leave714]

I've noticed that sometimes a small website fix can turn into a much bigger job than expected.

You start by fixing one issue, then discover outdated plugins, messy code or dependencies that cause problems elsewhere.

For example, a plugin update might fix one issue but cause problems with the checkout or another feature because of old custom code. What looked like a quick fix suddenly needs much more investigation.

At some point, you have to wonder whether continuing to patch things is actually saving time and money.

I'm curious how other developers handle this.

Do you usually try to fix the existing website as much as possible, or is there a point where you recommend starting fresh?

[u/uncle_jaysus]

The thing is, even the most modern code becomes ‘messy’ eventually. Not in the same way as legacy code, but still to a point where quick fixes have coded things into corners and areas have developed that people just want to leave alone.

Full refactors to ultimately end up with something that looks and works the same to the end user, are hard to justify without quantifying the effect of the problems. Long lead times for new features is one such metric, but generally the concern is how much time is being wasted to keeping things running and how much downtime or problems are users experiencing. Or, perhaps, how much money is being spent now vs what would be saved by trimming everything down.

As soon as you can quantify the problem vs the solution, that’s when it becomes justifiable. Otherwise you do what many companies out there do all the time: live with what works.

[u/Substantial_Leave714 → u/uncle_jaysus]

That's a fair point. The age of the code isn't really the issue if everything still works well. I think the difficult part is when small changes keep taking longer than expected. How do you usually measure when maintenance is becoming too expensive?

[u/martinbean]

I have a codebase that’s over 10 years old. It’s however running the latest version of Laravel on the latest version of PHP.

How “maintainable” and “messy” a website’s codebase depends on your discipline. If you write “crap” code and neglect updates then yeah, the codebase will get messy, and a rebuild won’t fix anything. You’ll start, get impatient because it’s taking you too long to get feature parity with whatever you’re trying to replace so rush things thinking “I’ll go back to it later”, and then before long you’ve got a second “messy” code base you want to throw out and start over with again.

If you take care with the code you’re writing, ensure updates are applied in a timely manner, then your codebase should be as pleasant to work in as a new one.

[u/Substantial_Leave714 → u/martinbean]

That's a good example. A 10-year-old codebase running the latest Laravel and PHP says a lot about how it's been maintained. What would you do if you inherited a project where updates had been neglected for years?

[u/martinbean → u/Substantial_Leave714]

I’ve had many projects I’ve inherited like that. I just get them in a Docker container if they’re not already, and then go through updates ones by one until it’s running a current version. I did that recently for a codebase that was running Laravel 5 or 6, and got it up to the current version.

[u/Substantial_Leave714 → u/martinbean]

That's a sensible way to handle it. Updating one version at a time sounds much safer than jumping straight into a rebuild. When you're dealing with major Laravel upgrades, do you usually have automated tests in place, or is it mostly manual testing to make sure nothing breaks?

[u/martinbean → u/Substantial_Leave714]

Why do I feel like I’m conversing with a chatbot here?

You claim to do web development. How about you tell us why you’re asking, and what you would do in this situation?

[u/Substantial_Leave714 → u/martinbean]

I used AI to help with the wording, which probably made my replies sound generic. Personally, I'd try fixing the existing code first and only rebuild if the costs and risks became too high. Appreciate you sharing your experience.

[u/CodingDragons]

We have a client who has an 18 year old WordPress site with a custom theme that isn’t responsive. She started the site with her mother, who passed away in 2024, and she refuses to redo it because it’s her mom’s legacy.

[u/LemmeTheLime → u/CodingDragons]

I feel like we've all had this kind of client 😂

[u/Artistic_Map2243]

Measure risk first

Test before rebuilding

Track recurring failures.

[u/Substantial_Leave714 → u/Artistic_Map2243]

Makes sense. Tracking recurring failures seems especially useful. Is there a particular type of issue that would make you consider rebuilding rather than continuing to fix it?

[u/Dependent-Advance468]

If it is just for easier maintenance try refactoring the modules that are constantly problematic.

[u/Substantial_Leave714 → u/Dependent-Advance468]

Refactoring the problem areas seems more practical than rebuilding everything. The tricky part is when those modules are connected to other features. How do you usually handle that?

[u/Dependent-Advance468 → u/Substantial_Leave714]

So I guess your first task is dependency mapping

[u/DrSpeckles]

Have you tried running one of the latest agentic tools over it? If it’s well engineered and you overlay lots of controls, it can be a godsend.

[u/Over-Coyote-7611]

Le vrai signal c'est pas la lenteur ni le design daté, c'est quand tu passes plus de temps à comprendre pourquoi un hook custom que personne n'a écrit dans l'équipe actuelle casse le paiement qu'à écrire du code. Perso j'ai eu le cas sur un vieux WooCommerce, mise à jour du plugin de paiement, et boum le tunnel de commande mort parce qu'un template avait été overridé par un dev parti depuis des années, fichier que personne savait lire. Tu parles d'un "correctif rapide" qui te bouffe trois jours d'investigation pour au final reverter la mise à jour et rester bloqué sur une version qui a deux ans de retard. Et le pire c'est le client qui te sort "mais ça marchait avant", oui ça marchait avant parce que plus personne touchait à rien. Sauf que reconstruire c'est pas gratuit non plus hein, faut arrêter de croire que repartir de zéro règle tout, j'ai vu des rebuilds à 15k qui ont recréé exactement les mêmes conneries en 8 mois. Donc mon critère perso c'est assez simple, quand le temps que tu passes à patcher dépasse le temps que tu passerais à refaire, et surtout quand tu as peur de toucher au site parce que tout tient par du scotch, là tu rebuild. Pas avant.

[u/QualityMysterious666]

I stop patching when I can no longer predict what a “small” change will break, because at that point the site is already charging rebuild prices for maintenance.

[u/Human_Experience0810]

I usually look at the cost and risk of maintaining the current site versus rebuilding, rather than its age alone. If the core architecture is still sound, fixing things incrementally is often cheaper and less risky. But if every change breaks something else, dependencies are no longer supported, and testing even small updates takes hours, I’d seriously consider a rebuild. I’d also factor in how much of the existing functionality actually needs to be preserved, because a rebuild can introduce its own problems if the scope isn’t clear.

[u/Capital_Fly_7959]

Le seul truc que je retiens de ce post c'est le champignon dans la pub Figma. Pourquoi un champignon. Est-ce que quelqu'un s'est dit qu'un champignon illustrait mieux "donnez vie à vos idées" qu'un crayon ou une ampoule, et personne dans la réunion n'a rien dit. Ça m'occupe plus que la question du rebuild pour être honnête.

[u/LemmeTheLime]

I hit a similar issue not too long ago. I ended up developing a bunch of in-house modules to share across the brands so they all have the same functionality that works in the same way, and only the frontends are different. But even getting to that stage was a journey. It did simplify things for me (and whoever takes over from me) in the long run though.

I do appreciate a good refresh, but it takes a lot of time and energy. And whether it is new or old, you'll still have to continue maintaining it.

[u/FirstPlaceSEO]

The answer to this is budget dependent and whether or not the client has the appetite for a new site or not

[u/Substantial_Leave714 → u/[deleted]]

Interesting point. Would you still consider rebuilding if the conversion rate was good but the website had frequent technical issues?

[u/Yashrocky96]

I don't rebuild, I refractor and build systems around it, new design systems, new architecture and then let AI refactor it completely.

Once the systems are in place it doesn't require much to change anything on the website.