Is it safe to delete old, disabled modules from the back office?

Generally yes, but uninstall first, do not just delete the folder. Disabling a module only switches it off; its database tables, hooks and config rows stay behind. The right order is:

The normal path is Modules > Module Manager, then search for the module, open its action menu and choose Uninstall. After uninstalling, PrestaShop can remove the module folder, or you can delete the folder from modules/modulename/ once the uninstall completed cleanly.

Some modules intentionally keep historical data after uninstall, especially payment, order, shipping, support, marketplace and audit modules. That is not always a bad uninstall routine: invoices, order references, validation logs or license history may need to stay readable even when the module is disabled.

1. Back up your database and files first, so a bad cleanup is reversible.
2. In the back office, click Uninstall on the module. This runs the module's own uninstall routine and removes the data it created.
3. Then delete the module folder (the back office can do this for you after uninstalling).

Skip the uninstall and delete the folder directly, and you leave orphaned tables and hook records in the database. For white-screen and 500-error recovery, see our PrestaShop troubleshooting guide.

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 = 'modulename';

SELECT id_tab, class_name, module, active
FROM ps_tab
WHERE module = 'modulename' OR class_name LIKE '%ModuleName%';

There are two cases where you should pause: if the module provided payment, shipping, tax, marketplace or ERP integration, first confirm there are no active orders, carriers, webhooks or cron jobs still depending on it; and if the module is custom, inspect its uninstall routine because some modules intentionally keep historical tables for audit reasons. A good cleanup is to uninstall one module at a time, reload the back office, open the front office, and check the PHP error log before continuing.

Module source usually explains why the back-office uninstall step matters. Well-built modules remove tabs, configuration, hooks and sometimes custom admin preferences in their uninstall() method. Deleting only the folder skips that cleanup and can leave broken menu entries, dead hooks or database tables that make later upgrades harder to debug.