Archiving old orders in PrestaShop: a fast back office without losing invoices

You open “Orders” in the back office and it takes a while. You filter by customer and it takes even longer. The store has been selling for years, and every order has left rows in around twenty tables: lines, status history, payments, invoices, carriers, messages, the cart it came from. None of those rows goes away on its own.

The temptation is to delete old orders. Don't: you have retention obligations, and an order deleted by hand in PrestaShop leaves orphans in other tables. What you can do is archive.

Why it becomes slow

The PrestaShop order list does not query a single table. To display each row it joins the order with the customer, the address, the country, the current status and the currency, and to filter and sort it has to go through a lot of rows. With tens or hundreds of thousands of orders, every search works on the whole history even if you only want to see this week's.

It also affects other screens: the customer page, statistics, some modules that calculate things from the order history, and exports.

Archiving is not deleting

Archiving means taking old orders out of the active tables and storing them in full in other tables, where they can be consulted and, if necessary, brought back. The difference from deleting is total:

• The order still exists with all its data: lines, amounts, taxes, invoices, credit slips, payments and messages.
• You can search for it and view it when a customer or your accountant asks for it.
• You can restore it with the same number if it is needed again in day-to-day work.

Commercial and tax law require you to keep invoices and documentation for years. Archiving is compatible with that; deleting is not.

What has to travel with each order

An order in PrestaShop is not one row. If you only move the orders table, the rest is left dangling. At the very least, these must go together:

• The order and its lines.
• The status history.
• Invoices, delivery slips, payments and credit slips.
• Returns and their lines.
• Carrier and tracking.
• The cart it came from and its products.
• The order messages.

And it has to be done as a transaction: either the whole order is moved, or nothing is. An archiving run that fails halfway and leaves half an order on each side is worse than not archiving.

The numbering pitfalls

This is the detail that causes the most trouble. PrestaShop calculates the next order, invoice and delivery slip number from the ones that exist in the tables. If you archive precisely the order that has the last invoice number, PrestaShop may “not see it” and repeat the number on the next invoice. A duplicate invoice is a serious tax problem.

Prudent rules:

1. Never archive the order that has the last order, invoice or delivery slip number.
2. Prevent a new order from receiving the number of an archived one.
3. If you use your own series or numbering with another module, check on a copy how it calculates the next number before archiving.

Which orders to archive

The usual criterion is age, but it is worth refining:

• Minimum age. Six months or a year is a reasonable starting point; it depends on your returns and warranty periods.
• Statuses. Only closed orders: delivered, cancelled, refunded. An order awaiting payment or being returned is not archived.
• Recent activity. If an old order has had a status change recently (a late credit slip, a warranty claim), better wait.
• Split orders. If a cart generated several orders, they are archived all together or not at all.

What changes for you and for the customer

An archived order leaves the core tables, so:

• It no longer counts in PrestaShop's core statistics.
• It does not appear in the customer's “My account” history until you restore it; it is a good idea to tell them, with a short text, that their old orders are archived and that they can request them.
• Modules that calculate things from the history (loyalty, segments, recommendations) will stop seeing it. Check which ones you use.

How to do it sensibly

1. Full backup of the database before the first archiving run.
2. Simulation: count the candidates and the rows that would be moved, without moving anything.
3. Small batches at first, and check the archive list and a restoration.
4. Automate with a scheduled task and an email report of each run.
5. Keep permanent deletion locked. If anything is ever deleted from the archive, it should require deliberately unlocking it and a specific permission.

A note on versions: if your store is still on an early 1.7 or on 1.6, archiving relieves the back office, but it is no substitute for upgrading. PrestaShop 8 and 9 with a current PHP version also perform better on the same queries. If you are going to migrate, archiving beforehand reduces the volume of data that has to be moved and tested.

Frequently asked questions

Can I still issue a credit slip for an archived order? Not directly: you restore it first, issue the credit slip as usual and, if you wish, it goes back to the archive on the next run. That is why the minimum age should exceed your returns and warranty periods.

Does archiving free up disk space? It moves rows from some tables to others, so the total size of the database does not go down. What improves is the speed of queries on the active tables. Optimising the tables after each run helps recover part of the space left by the gaps.

And my accountant, can they still ask for old invoices? Yes. Invoices stay stored with the archived order and can be consulted or restored whenever they are needed.

How to solve it in PrestaShop

RKR Order Archive takes old orders out of the active tables and stores them in full, with their 20 tables (lines, history, invoices, payments, returns, credit slips, cart and messages), in an archive with a list, search and filters. You choose the age, statuses, store, minimum amount and size of each run, and you can exclude orders with recent activity. It includes a simulation mode, a cron job with its own token, an email report and exact restoration with the same number. Each operation is a transaction, it does not archive the order with the last invoice, delivery slip or order number, it waits until split orders can be archived together and it keeps permanent deletion locked by default.