# Maintaining a custom module over time

> A custom module is not a finished object. The platform changes version, PHP removes functions, a third-party API changes its response format: the module hasn’t moved, but its environment didn’t wait for it.

- Source canonique : [https://allaux.fr/en/modules/maintenir-un-module-dans-le-temps](https://allaux.fr/en/modules/maintenir-un-module-dans-le-temps)
- Langue : EN
- Dernière mise à jour : 2026-08-03

## What moves under a module even when nobody touches it

Three layers evolve independently of you. The platform first: a major version change can remove a hook point, rename a method or replace an entire section of the admin. PHP next: each release drops deprecated functions, and a module written a few years ago can stop working at the first server update, often decided by the host rather than by you. Finally the outside services: a carrier, a payment gateway or a management system can change its interface, with notice nobody passes on to you unless you follow their technical announcements.

A module that only displays things lasts a long time. A module that talks to an outside system is the one that needs the most attention, because the failure will come from somewhere other than its own code.

## What I actually do under maintenance

- **Track versions** — Before each platform or PHP upgrade, check that the module stays compatible, and adapt it when it doesn’t.
- **Watch outside exchanges** — Log calls to third-party services, so a failure is visible the day it happens rather than a week later.
- **Fix unforeseen cases** — In production a module meets situations testing never imagined. Those fixes are part of the normal life of a build.
- **Keep the code handover-ready** — Up-to-date sources, identified dependencies, a written install procedure: enough to hand the module to someone else at any time.

## What maintenance does not cover

I keep three things clearly apart, because conflating them is the first source of disagreement. Fixing a defect in the module is maintenance. Adapting to an outside change — a new major platform release, a new format imposed by a partner — is identifiable work, quoted separately when it is significant. Adding a new feature is development, however small, and it is treated as such.

I say this up front because the opposite doesn’t hold: a maintenance retainer that absorbed any change request would either be overpriced or honoured at the expense of what it exists for. Stating the boundary beats discovering it mid-project.

## The best maintenance investment happens upstream

> A module that logs its errors, keeps its settings in configuration rather than in code, and depends only on stable hook points needs far less upkeep. Those choices cost almost nothing while writing and pay for themselves at the first upgrade.

## Related pages

- **Maintenance and managed support** — The wider frame beyond a single module: updates, backups, monitoring. ([/services/maintenance](/services/maintenance))
- **A module broken by its own update** — When the failure lands exactly at a version change. ([/modules/module-casse-apres-une-mise-a-jour](/modules/module-casse-apres-une-mise-a-jour))
- **Preparing a major upgrade** — The preparation method, at whole-store level. ([/guides/preparer-mise-a-jour-majeure](/guides/preparer-mise-a-jour-majeure))
- **Auditing a store’s module estate** — To know what deserves maintaining and what deserves removing. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))

## FAQ

### Is maintaining a module compulsory?

No, and a simple, well-isolated module can run for a long time untouched. It becomes necessary as soon as the module exchanges with an outside service or touches payment, because there the failure comes from outside.

### What happens if I do nothing for two years?

Usually nothing visible, until the first PHP or platform upgrade. That is when the accumulation is paid for in one go, and picking things up after a long silence costs more than steady follow-up.

### Do you maintain modules you didn’t write?

Yes, after spending time reading the code. I won’t commit to maintaining a module I couldn’t read, particularly if it ships in encoded form.

### Does maintenance include backing up the store?

That is a separate subject, belonging to hosting and whole-site management. A module isn’t backed up separately from the rest: it is the complete store you need to be able to restore.