Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

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

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

attente
plateforme
historique (facultatif)
frequence-souhaitee (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages