# Taking over an abandoned website: fix or rewrite?

URL: https://rootcr.com/guides/taking-over-an-abandoned-website/
Updated: 2026-08-23

# Taking over an abandoned website: fix or rewrite?

> **In short:** With an inherited or abandoned project, the decision doesn't hinge on how pretty the code is, but on three things: whether all access credentials are in place, whether the system's structure is understandable, and how much would actually need to be rewritten. If the access is complete and the structure is followable, fixing is almost always cheaper. If access is incomplete or the system consists of exceptions at every point, rewriting is cheaper — even if it seems more expensive at first.

## The first step you can take today

Before you talk to anyone, secure these seven things. They're yours even if you stay with your current developer:

1. **Domain access** (at the registrar, in your name).
2. **Hosting or server access.**
3. **The website's admin interface** full-rights login.
4. **The source code** — in its entirety, not in fragments.
5. **The database** backup.
6. **Google Search Console and analytics** ownership rights.
7. **Email and DNS** settings.

If any of these is missing, that's the most urgent task — far more important than whether the code is pretty. Without access, it's not just the system you don't own — it's your company's online presence.

## What do I look at first?

When I take over a project, I don't look at the aesthetics of the code. I look for answers to four questions:

### 1. What is the system, actually?

A template? A template plus fifteen extensions? Custom code? A framework that was outgrown? This determines how much each thing costs from here on.

### 2. How many exceptions are there?

This is the best predictor. If the system consists of “we'll just quickly patch this here too” at every point, then every change is a risk and every estimate will be a lie. If there is order in it — even simple order — fixing is predictable.

### 3. Is there a security risk right now?

Outdated components, endpoints without authentication, unvalidated file uploads, passwords in the source code. This part cannot wait for the big decision: whatever can be closed today, we close today.

### 4. Where do things stand in search?

How many pages are indexed, which queries bring traffic, whether there is a position that a bad migration could lose. This determines how careful you have to be with the URLs.

## The decision rule

| Sign | Fix | Rewrite |
|---|---|---|
| All access is in place | ✓ | |
| The structure is followable, there is order in it | ✓ | |
| The error is confined to a well-defined part (a form, one module) | ✓ | |
| The content and search positions are valuable, the URLs are good | ✓ | |
| The source code or a key access is missing | | ✓ |
| Every change breaks something else | | ✓ |
| The system's underlying assumption doesn't fit the process | | ✓ |
| A known, unfixed security flaw in the system's core | | ✓ |
| Five or more paid extensions keep it alive | | to be weighed |

The most important row is the third from the bottom: **if the system's underlying assumption doesn't fit the process, the fix never ends.** Not because the developer is bad, but because every new requirement becomes yet another exception. The [WordPress versus custom](/guides/wordpress-vs-custom-website/) decision is about this too.

## What can you carry over in a rewrite?

- **The content** — text, images, product data are exportable.
- **The search positions** — redirects run from the old URLs to the new ones. This technical step decides whether traffic grows or falls after the rewrite.
- **The customer and order data** — migrated from the database.

What you don't carry over: the technical debt. That's the goal.

## How does it work with me?

First I review the existing system and tell you in writing what I found, what the risk is right now, and whether fixing or rewriting is worth it. This is a few hours of work, and you get an honest answer even if that answer is that the current system is worth keeping, or that you're better off with your current developer.

If we decide on the rewrite, the new system is built in parallel, and the switchover happens at a single, agreed-in-advance moment, with redirects in place.

## Frequently asked questions

### The old developer won't hand over the access credentials. What should I do?

Request it in writing, citing the contract and the fact that the domain and the data are yours. At the registrar, the domain can usually be transferred with proof of ownership. Unfortunately this is a common situation, and it improves fastest if you ask for it in writing, dated.

### How much does the review cost?

A few hours of work billed at an hourly rate. At the end of it you receive a written opinion — even if I'm not the one who continues.

### Will I lose my Google rankings?

If someone takes the redirects seriously, no. If they skip them, yes — which is why this step appears as a line item in every offer I make.