Remove PrestaShop modules without losing needed data

What we would do

We would repair a limited fault in a needed module before retiring it. The choice depends on your existing shop: its modules, integrations, theme, historical data, markets and the staff who use its output.

Check the footprint on a staging copy with your theme, PHP version, other modules, caches and multistore configuration. Isolate the copy from live emails, payments, exports and other production integrations. Use test accounts or block calls that could change live external data before rehearsing uninstall. Rehearse the removal sequence and recovery there, then agree a live change window and who checks the result. A successful install on a clean test shop does not cover those interactions.

If slow pages prompted the removal, the PrestaShop Speed & Core Web Vitals Audit can identify the requests and code involved before you choose a fix.

Understand a module's footprint

A module runs PHP with the database and filesystem privileges available to the shop process. It can register hooks, change tables and configuration, add overrides, edit accessible files and call external services. Its practical reach depends on server permissions and the code it executes.

Judge module quality by ownership, review, testing, maintenance, compatibility and reversible changes. The use of AI-assisted development does not answer those questions for you.

Separate disable, uninstall and file deletion

Disabling is not a PHP execution boundary. A standalone endpoint or externally scheduled script can remain reachable unless its code checks module state or you remove access separately.

Uninstalling is not a rollback of all past operations. Data already written to an order, customer record or external service needs its own handling.

Follow a safe removal sequence

1. Back up the database and files. Keep the module package and its version details. Confirm the backup can be restored; reinstalling code alone does not recreate deleted data.
2. Check active orders, payment callbacks, carriers, tax rules, marketplace feeds, ERP links and other modules that depend on it. Check URLs the module owns and plan replacement routes or redirects.
3. Read the retention and uninstall policy. Export records you need, and confirm how you will read historical invoices, shipping data or audit records afterwards. Open an exported sample without the module installed on staging.
4. Pause or replace dependent scheduled work and integrations in a controlled order. Let in-flight work finish or document its supported recovery.
5. Open Modules > Module Manager, find the module and choose Uninstall.
6. Confirm uninstall completed successfully. Resolve errors before removing code needed by cleanup.
7. Use the back-office file-removal option where available, or remove the module directory after successful uninstall.
8. Clear the supported application cache and test the back office, storefront and affected order flows.

Remove one module at a time and read the PHP error log before continuing. In multistore, disabling can target selected shops, while core uninstall removes the module registration across the installation. Registered overrides and module files are shared, so check the effect on every shop before proceeding. Do not remove files while another shop still relies on them.

Repeat the rehearsed sequence on current live data. Replacing production with an older staging database can discard orders and customer changes received since the copy.

Inspect retained data and leftover integrations

Database and admin records

Payment, shipping, support, marketplace and audit modules may deliberately retain historical tables. Establish why the data is kept and how long it is needed before deleting it. Do not drop shared package tables because one module used them.

For a read-only registration check, this example looks up Cron Manager. Use your actual table prefix and the installed module name when adapting it:

SELECT m.id_module, m.name, h.name AS hook_name
FROM ps_module m
LEFT JOIN ps_hook_module hm ON hm.id_module = m.id_module
LEFT JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.name = 'mprcron';

SELECT id_tab, class_name, module, active
FROM ps_tab
WHERE module = 'mprcron';

These queries inspect registrations, not every table, setting or file the module may have created. Use the module's installer and uninstall code to identify those objects.

Overrides and theme edits

Normal core lifecycle handling removes correctly registered overrides. Manually copied overrides, theme edits and files left by a failed uninstall need separate inspection. Do not delete an entire shared override file without checking which code belongs to other modules.

Jobs, endpoints and services

Review server cron entries, shared scheduler registrations, webhooks, queue consumers and scripts called by external services. In a shared scheduler, remove the obsolete task while keeping other modules' schedules intact. Revoke unused credentials and remove obsolete callbacks at the service end. Decide what to retain or delete in remote systems under the applicable retention policy.

Check assets and behaviour before and after removal

A global storefront hook can add CSS, JavaScript or remote fonts to pages that never use the feature. On a client's shop, a decorative font used only on a module's settings screen also loaded on the homepage, category, product, cart and checkout pages. We kept the useful feature and corrected the storefront registration; an admin-only font belongs on the relevant admin screen.

For example, a font added by hookDisplayHeader() can reach storefront pages. Remove the font stylesheet’s registration when the storefront does not use it. Preserve any other assets or behaviour that the same hook still needs. In hookDisplayBackOfficeHeader(), scope the asset to the module's configuration page or controller. A check against the configure parameter only covers the configuration-page route, so use the actual controller condition for dedicated admin pages.

1. Record a baseline in the browser Network panel on home, product and checkout pages, with browser caching disabled for both runs. Keep the request URL and initiator, not just a speed score.
2. Repeat after installation, removal or a scoped repair with comparable cache and network conditions.
3. Inspect new domains, transferred assets and browser errors. If an unwanted request remains, follow its initiator to a theme asset or combined cache before blaming the uninstall.
4. Complete the affected checkout or account workflow and confirm background work behaves as intended. After a scoped repair, also check the module’s feature and settings screen to confirm the required assets still load.

If removal fails or causes a 500 error, keep the logs and restore through your tested recovery procedure. Do not continue deleting files until you understand the failure.

What to ask your developer or agency

• Which files, tables, settings and shared dependencies change, and which deliberately remain?
• Can staff still retrieve an old invoice or process a refund without the module?
• Which staging results prove checkout, callbacks, jobs and every affected shop still work?
• Who owns the live switch, the decision to stop and recovery, including orders received during the change?

Questions owners ask

Will removing a module cancel its subscription?

Check renewals and cancellation in the supplier account separately. Removing shop files does not establish that an external subscription or contract has ended.

Should I use Reset to test removal?

Treat Reset as potentially destructive. It can run uninstall and reinstall logic, so check the installed module's data policy and rehearse the action before accepting it.

Should an unused module stay installed indefinitely?

Give retained code a documented purpose, an owner and a review point. If historical access still needs it, plan an alternative before removal. Disabled code still needs maintenance.