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.
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.
Related pages
-
Maintenance and managed support
The wider frame beyond a single module: updates, backups, monitoring.
-
A module broken by its own update
When the failure lands exactly at a version change.
-
Preparing a major upgrade
The preparation method, at whole-store level.
-
Auditing a store’s module estate
To know what deserves maintaining and what deserves removing.
- 2019 e-commerce developer since
- 3 platforms: PrestaShop, WooCommerce, Shopify
- 3 working languages: FR, EN, TR
- 100 % direct contact with the developer
No middleman: the person who replies is the one who works on the code.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.