Maintenance
Shop maintenance
PrestaShop
In an online shop, a failure costs more than on a company website. Every hour without a working basket means lost orders, and some customers will buy from a competitor in the meantime.
Why a shop needs different maintenance from a website
PrestaShop is a far more complex system than a typical company website. Besides the core and the theme, it usually runs a dozen or more modules: payments, shipping, warehouse integration, invoicing and marketing. Each of them affects orders and payments.
On a company website, a typical failure is a form that does not work. In a shop, failures can be quieter and more expensive: the payment goes through, but the order is not saved in the system. Or the basket works on a computer, while on a phone the order button disappears under the cookie bar.
That is why shop maintenance includes, alongside updates, a regular run through the whole purchase path: from the product page, through the basket and delivery, to a real test payment and the email confirmation.
Scope of ongoing shop maintenance
The starting point is a list of tasks carried out on a regular cycle. On top of that come issues reported as they arise, handled within the hours of your chosen plan.
- Core and module updates, always on a test copy first
- Backup of files and database outside the shop server, with 30-day history
- Monthly test purchase: basket, delivery, payment, invoice, email
- Availability monitoring every 5 minutes and shop response time
- Checks that warehouse and courier integrations work correctly
- Performance review of product listings and the internal search
- Database clean-up: abandoned baskets, logs, old sessions
- A pool of hours for changes to content, categories and configuration
Old versions: when to upgrade and when to rebuild the shop
Older PrestaShop versions, such as 1.6, no longer receive security fixes. Upgrading to version 8 or 9 can be simple, but with a heavily customised theme and a dozen or more paid modules it becomes a project of its own.
Before we recommend anything, we check three things: how many modules have equivalents in the new version, how much the theme has been changed and whether there are custom changes in the core code. The last point matters most, because an upgrade overwrites such changes, and you only find out they are gone after deployment.
Sometimes we recommend building a new shop and moving the data instead of upgrading. A shop like that is easier to develop later. We tell you this plainly, even when it means a bigger project than you expected.
| Situation | Recommendation |
|---|---|
| Standard theme, a few modules | Upgrade to version 8 or 9 |
| Customised theme, paid modules | Upgrade in stages |
| Changes in the core code | New shop build and data migration |
| Shop on 1.6 with no support from module authors | Migration, including to WooCommerce |
Payments and shipping: the most common sources of silent failures
Payment modules update independently of the shop, and their providers change from time to time how they communicate with the shop. A common scenario is an expired key or a changed notification URL, after which the payment is taken but the order stays in pending status.
We check this with a monthly test: a real low-value transaction, a run through the whole path and a check that the order changed status, the email went out and the sales document was generated. We refund the amount, and the test result goes into the report.
The same applies to shipping: courier rates change, so we check that delivery costs in the shop are calculated using the current rates. An error here is easy to miss, because it does not block orders.
A shop that has stopped working is noticed straight away. It is harder to spot a situation in which everything looks normal, but orders are not coming through.
Shop performance as the catalogue grows
PrestaShop slows down in a predictable way: with the number of products, combinations and filters. A shop that ran well with five hundred products can take several seconds to load a listing with five thousand, and that translates into more abandoned visits.
The typical causes are well known: missing database indexes after an import, filters recalculated on every visit, caching switched off and images served at their original size. If your shop has a large catalogue, see also database optimisation.
With larger catalogues we also check whether the server meets the requirements. Code optimisation alone will not fix a shop with over ten thousand items on cheap shared hosting. We offer several types of hosting, including plans for PrestaShop shops, and we choose the plan to suit the size of the catalogue and the traffic.
Warehouse and accounting integrations
A shop often exchanges data with a warehouse system: stock levels, prices, orders and sales documents. This exchange can be the most sensitive part of the whole setup, because an error on one side immediately carries over to the other.
As part of maintenance, we make sure the synchronisation works and that errors do not get lost in the logs. We check the number of synchronised items, catch products that have dropped out of the exchange and act when stock levels in the shop start to drift from the warehouse. More about the connections themselves: ERP integrations.
What affects the cost of shop maintenance
A shop needs more work than a company website. The cost of maintenance depends on the size of the catalogue, the number of integrations and the number of hours for changes included each month, so we price every shop individually. Below are the scope options.
| Option | Who it is for | Pool of hours for changes |
|---|---|---|
| Security | Small shop | Smallest |
| Standard | Shop with warehouse integration | Larger |
| Growth | Shop with traffic and campaigns | Largest, with an individual response time |
Hours not used in a given month carry over to the next, up to the size of one package. In a busier month you have hours to draw on, and in a quieter one we do not fill the time for the sake of it.
Jakub is very professional and has made running my company much easier.
Taking over a shop from another contractor
When we take over a shop from another contractor, we start with an initial review: what is installed, in which version, where the backups are, which modules are paid and whether the licences are assigned to the right company.
That last point can be an unpleasant surprise. Paid modules bought on the contractor's account keep working, but they cannot be updated without the contractor's involvement. We help sort this out by transferring the licences or buying them again. We tell you the cost before you decide.
The initial review is free and ends with a list of findings ordered by urgency. Even if you decide not to work with us, you know what state your shop is in.
- Paid modules assigned to a former contractor's account
- No test environment, so changes go straight to the live shop
- Backups stored only on the shop server
- Core without security updates for years
- Changes made directly in the core code
Working together
How we work together, step by step
Initial review
Versions, modules, licences, backups, performance, security. A report with a list of findings.
Clean-up
Test environment, off-server backups, overdue updates, monitoring.
Regular work
Updates on a copy, test purchase, integration review, monthly report.
Ongoing requests
Changes and minor fixes within the hours of your plan, with clear priorities.
Shop development
New features and integrations quoted separately and deployed on a copy first.
Questions
Frequently asked questions
Versions from 1.6 to 9. With older versions we start with an initial review and tell you whether it is better to upgrade the shop or to rebuild it and move the data.
Yes. We have various hosting packages, including ones for PrestaShop shops. We choose the plan after a short conversation about the size of your catalogue and your traffic.
Yes, we work with both systems. When a shop has to be built from scratch, we help you choose the platform. More on this under online shops. When migrating from PrestaShop, we move products, customers and orders together with redirects.
Yes. We prepare the upgrade on a copy, test the full purchase path and only then switch over. Downtime is usually limited to a few minutes, and we schedule it for the quietest time of day.
We check the extent of the changes before upgrading. If the customisations are in the theme, they can usually be carried over. If they are in the core code, we tell you plainly, because that changes both the cost and the recommendation.
Yes, with a real low-value transaction that we then refund. Sandbox tests miss some problems that only appear in production.
During business hours we usually pick up the issue within two hours. In the Growth plan we agree individual response times, including outside standard hours.
Yes. Before periods such as Black Friday, we check performance under load and prepare the shop for higher traffic. We do this in advance, before the campaigns start.
Related services
What else may be useful
Your city
PrestaShop shop maintenance in your city
For each of these cities we have a separate page describing the local market and how we work with companies there.
We will look after your PrestaShop shop
Give us your shop's address and we will carry out a free initial review and tell you what needs urgent attention, what can wait and what can be fixed right away.