How to Salvage a Deprecated Site

It’s the quintessential web developer complaint:

“The last person who worked on this had no idea what they were doing”

And sure, it’s easy to complain about. But almost every web developer is guilty of cutting corners, especially those who have bosses with a limited understanding of the process and who give unreasonable deadlines as a result.

However, there’s a certain art to picking through the pieces of someone else’s code and trying to tune it up. Most of the time it might be easier to start from scratch, using tools that you’re familiar with.

But that would forgo a great opportunity to pick apart another developer’s thought process and find out what didn’t age well, what methods became unwieldy and what choices you hadn’t thought of.

So don’t look at the code as a junk car that’d be better off being crushed into scrap. Look at it as a fixer-upper. Or at the very least, see it as a chance to learn how to make your sites more future-proof and manageable.

Site Platform

Well, this is where things can go south quickly. Depending on what platform the last developer gambled on, you might end up with something that’s borderline unchangeable.


To cite my own experience, one site I was hired to salvage relied entirely on a WordPress theme that was three years out of date. The live site just barely managed to hold together, but if I made one tweak to any code, it would all fall apart.

On top of the theme itself, most of the plugins were out of date and some didn’t even have versions that worked with the WordPress version that the site was using.


Depending on how flexible the platform is, it might be possible to update or change the template with relative ease. Otherwise you’ll have to recreate the site with a new theme, which will take time but definitely pay off long term.

To avoid doing this to future web developers, remember this simple rule: The fewer plugins, themes and fringe JavaScript libraries you use, the better. It might be a safe bet to use major libraries like jQuery or Angular/React, since they’re likely to be supported for a while.

But you want to avoid relying on something like a header/footer WordPress plugin to load your above-the-fold JavaScript files. If a WordPress update breaks that plugin, you’re at the whim of the plugin developer to fix it while your site falls apart.

For WordPress, best practices involve either using an enqueue function or adding the code into the header.php file. These methods are core to WordPress and likely to stand the test of time.

Server File Structure

This is where things can get messy. You might have scripts hiding in three separate folders, multiple leftover website versions taking up space or an endless number of unused stylesheets.

Once you’ve decided the new direction you’re going to take for a site, make sure to clean up anything that isn’t being used anymore. It’s probably best to be safe and download them locally and put them in a backup folder, just in case you end up needing it again or if you find out it was more crucial than you thought.


As mentioned above, all these extra files clutter your site’s file tree and add extra steps when digging around to edit or add assets. If you’re only using one theme, it’s a waste of time to have to click around five or six unused themes in your directory.


Before trying to clean up at all, I strongly recommend making a backup of your site beforehand. If you have access to cPanel, you can do it through that. Otherwise you can use something like FileZilla to FTP to your server and save the files locally.

After that, start to remove files that you’re positive aren’t being used anymore. But be careful. Don’t delete large chunks of your site en masse. Try deleting a handful of files and then hard refreshing your website. Make sure everything works and try clicking around on a few different things. And if things go catastrophically wrong, try to undo your changes or revert to your backup.


Surprisingly, this was the biggest headache for me. The developer before me had a Rube Goldberg machine setup to accept forms, forward them to an email, then use software to parse the data from the email, then add them into a CRM. This can be tricky and highly dependent on your needs.


Previous form setups might include logins to software you won’t have access to. Most developers will gladly hand over that information to new developers, but if you aren’t so lucky you can usually figure out your own route.


For the simplest, barebones solution for form submission, I strongly recommend FormSpree. They’ve got a great solution that involves posting to a URL that has your email at the end of it, and they forward you the emails. While this does involve relying on a third party, the solution is simple enough for about 95% of static website needs.

If you need something more complex, like submitting to a CRM, tools like Wufoo and Zapier should be enough to get you there.


Most web developers will, understandably, prefer to start from scratch and set up a site their own way. But as a new web developer myself, I’m glad I took the time to dig through old sites and find what methods did and didn’t age well.

It also helped to go through each element and ask “Is there a better way to do this?” and research best practices for script embedding, WordPress themes/plugins and collecting information from visitors.

Once I picked through each of these components, it made it infinitely easier to build my next site from scratch and use the best methods I had found for building it.