# My site has not been maintained for years

> A site that has run for years with nobody touching it is not a broken site. It is a site whose risk has been deferred, and whose bill arrives all at once — usually the day the host changes the PHP version, or the day a known vulnerability is exploited. Before deciding anything, the real gap has to be measured.

- Source canonique : [https://allaux.fr/en/problemes/site-laisse-sans-maintenance](https://allaux.fr/en/problemes/site-laisse-sans-maintenance)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Start with a backup you hold yourself: an archive of the web directory and a mysqldump of the database, stored on your own machine. Then record the CMS version, the PHP version shown in the hosting panel and the date of the most recently modified file, and list every module and plugin with its version number. That gap, not the age of the site, decides what has to be rebuilt.

## What "it still works" really means

A frozen site keeps working as long as its environment does not move. The problem is that the environment moves without you: hosts withdraw old PHP versions, browsers tighten their requirements, payment services change protocols, mail providers strengthen authentication checks.

So the site does not degrade gradually: it works, then it does not, with no intermediate step. That is what makes the situation deceptive. The absence of symptoms is not a health indicator, it is simply the absence of a recent external change.

## Six things to measure before any decision

1. **The CMS version and its status** — Does it still receive security fixes, or is it at end of life? The answer completely changes the level of urgency, and it is public information.
2. **The current PHP version and the one coming** — That is the real countdown. A host announcing the withdrawal of a version sets the date on which the site will stop if nothing is done.
3. **The state of modules and plugins** — For each: latest published version, publisher still active or not. An abandoned component will never receive a fix, whatever vulnerability is found.
4. **How much was modified inside the core** — A directly edited core prevents any clean update. Quantifying that volume often decides on its own between repairing and rebuilding.
5. **Whether backups exist and are valid** — A backup never restored is not a backup. It is the first thing to put right, before any update at all.
6. **Who holds the access** — Domain, hosting, third-party accounts, module licences. An old site has usually passed through several contractors, and ownership is rarely clear.

## Do not launch a major update as your first move

> On a site several versions behind, updating is not a button: it is an operation to prepare, on a copy, with an inventory of incompatible components made beforehand. Run straight in production, it turns a theoretical risk into an immediate outage, and with no verified backup there is no way back.

## Repair or rebuild: what tips the balance

I never answer that question before the inventory, because the answer rests on measurable facts rather than an impression. Arguing for an upgrade: an unmodified core, modules still maintained, a theme whose customisations are isolated, a catalogue and order history that would be costly to migrate.

Arguing for a rebuild: a heavily modified core, a majority of abandoned modules, a purchased theme whose publisher has vanished, a CMS version so old that the migration path runs through several successive steps. In that last case the upgrade effort approaches that of a new site, without giving the benefits of one.

Between the two there is a middle path: secure what is exposed first, then plan the rebuild without urgency.

Content, addresses and history are preserved in both scenarios; it is the code that is replaced or not.

## Related pages

- **Abandoned modules and plugins** — How to assess the risk of a component whose publisher has stopped shipping. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **PHP versions at end of life** — Why the PHP version is the real countdown for a frozen site. ([/securite/versions-de-php-en-fin-de-vie](/securite/versions-de-php-en-fin-de-vie))
- **Preparing a major update** — The method to apply before touching a site several versions behind. ([/guides/preparer-mise-a-jour-majeure](/guides/preparer-mise-a-jour-majeure))
- **Shop maintenance** — What regular upkeep covers, and what it does not. ([/services/maintenance](/services/maintenance))

## FAQ

### My site has never had a problem, so why update it?

Because the absence of incidents measures the stability of the environment, not of the site. The two events that trigger failure — a PHP version withdrawal, exploitation of a known vulnerability — give no warning sign visible from the site.

### How many versions behind can be caught up?

Technically many, but rarely in one jump. Version upgrades often run through mandated steps, and each step has its own module incompatibilities. That is what makes the work long, not the update itself.

### Can a site be secured without updating?

Exposure can be reduced: restrict access, remove unused components, fix file permissions, monitor. That buys time and does not replace updating, because the vulnerable code stays in place.

### What happens if I do nothing?

The site continues until the next external change. I can neither date that event nor promise it will not come; what I observe is that the cost of an imposed recovery always exceeds that of a planned operation.

### Where should I start on a limited budget?

With a full backup, tested by restoring it, and with taking back the access. Those two cost almost nothing and turn an unrecoverable situation into a repairable one.