PrestaShop Upgrade: Core, Modules, AutoUpgrade

A store on PrestaShop 1.7.8. After updating to 8.x — white screen, payment module not working, theme broken. This situation is familiar to many store owners. Directly copying core files without AutoUpgrade breaks the database. We guarantee data integrity and stability after migration — we have over 50 successful PrestaShop upgrades. According to statistics, 70% of stores encounter errors when upgrading on their own. Our process eliminates risks: audit, backup, tests on staging. We also check compatibility of all modules and themes before starting work. Moving to PrestaShop 8.x requires PHP 8.1 and higher — we set up the environment for your server. We bring the site up to current security and performance standards, improving Core Web Vitals. Savings on supporting an old version can reach 30% annually. Over 5 years of experience allows us to anticipate common problems.

Why is it important to upgrade PrestaShop?

Each new release closes security vulnerabilities, improves performance (Core Web Vitals, LCP), and adds support for current PHP versions. For example, PrestaShop 8.x requires PHP 8.1+ and is 20% faster than previous versions due to new caching. Delaying updates leads to technical debt: modules stop updating, themes become outdated, and the site can become a target for attacks.

How we upgrade PrestaShop: step-by-step process

1. Audit and backup Before any actions, we make a full backup of files and database:

   # Database
   mysqldump -u root -p prestashop_db | gzip > /backups/ps_db_$(date +%Y%m%d).sql.gz
   
   # Files (including override and custom themes)
   tar --exclude='./var/cache' --exclude='./var/logs' \
       -czf /backups/ps_files_$(date +%Y%m%d).tar.gz -C /var/www/shop.com .
   

   We also check the PHP version and module compatibility via their manifests (composer.json or manifest.xml).

2. Test upgrade on a staging copy We deploy a copy of the store on a separate server or subdomain. On it, we perform the upgrade via AutoUpgrade — this is the only supported tool for major transitions (1.6→1.7, 1.7→8.x).

   # Install autoupgrade module
   cd /var/www/shop.com
   wget https://github.com/PrestaShop/autoupgrade/releases/latest/download/autoupgrade.zip
   unzip autoupgrade.zip -d modules/autoupgrade
   
   # Install via Admin: Modules → Upload a module → autoupgrade.zip
   # or via CLI
   php bin/console prestashop:module install autoupgrade
   

   In Admin: Modules → Module Manager → 1-Click Upgrade. Before starting:

   • Disable custom modules that may conflict
   • Put the store into maintenance mode
   • Ensure backup is complete

3. Upgrade on production After successful testing, apply the same steps on the live server. Enable maintenance mode, run AutoUpgrade (or CLI if version 1.7.8+):

   php modules/autoupgrade/bin/autoupgrade check \
       --admin-dir=admin_secret
   
   php modules/autoupgrade/bin/autoupgrade update \
       --admin-dir=admin_secret \
       --channel=stable
   

4. Upgrade modules and theme After the core upgrade, update all compatible modules:

   # Via Admin: Modules → Module Manager → Update all
   # CLI via PrestaShop API
   php bin/console prestashop:module upgrade module-name
   

   Modules from the official Marketplace are updated via Addons → My modules. Third-party ones via FTP/Composer. If a module does not update, we look for a replacement or adapt the code.

5. Clear cache and final checks Run php bin/console cache:clear and php bin/console prestashop:generate:htaccess. Check all critical pages: catalog, cart, checkout, customer account. Check logs for errors.

Comparison: major vs minor upgrade

PHP requirements for different PrestaShop versions

What is included in the work (deliverables)

• Full audit of current configuration (versions, modules, theme, custom modifications)
• Creation of backup (files + DB)
• Deployment of staging copy and test upgrade
• Resolution of module and theme conflicts
• Upgrade on production during low-traffic window
• Functional verification and issue logging
• Training staff on the new version (if admin interface changed)
• 14-day stability guarantee after upgrade

How to check module compatibility before upgrading?

Before upgrading, run the command: php -r "define('_PS_ROOT_DIR_', '/var/www/shop.com'); require _PS_ROOT_DIR_.'/config/config.inc.php'; echo _PS_VERSION_;". Check modules' documentation for version requirements. If a module states support for a PrestaShop version, it should work. However, undocumented dependencies are common — they are only identified on staging.

Estimated timelines

Upgrade within the same major version: a few hours. Transition between major versions with full compatibility testing: 1 to 3 days.

Our experience and guarantees

We have been working with PrestaShop for over 5 years and are certified as official integrators. Over 50 upgrades without data loss — each client receives an individual migration plan. Request a free audit of your current PrestaShop configuration. Contact us for a project evaluation: we will analyze the configuration and provide exact timelines.

Website Technical Support: Updates, Monitoring, SLA

A website on Laravel 8 with PHP 7.4. PHP 7.4 is no longer supported, Laravel 8 also doesn't receive security updates. The hosting provider warned about the mandatory PHP update to 8.1 — after the update, two plugins and one library broke, the site went down. We regularly encounter such scenarios: a project without regular maintenance turns every environment update into an emergency.

This case is not an exception, but a rule. Commercial websites lose conversions due to slow loading, vulnerabilities, and downtime. We take care of monitoring, dependency updates, backups, and SLA — so you can focus on business, not the server.

Without systematic support, every environment update becomes a surprise: dependencies break, performance drops, security holes appear. Website technical support is insurance against such surprises and a guarantee of stable operation.

What Actually Goes into Website Technical Support?

Support is not "answering a call when something breaks." It is systematic prevention of breakdowns.

Dependency updates. Composer packages, npm packages, CMS or framework. composer audit and npm audit show known vulnerabilities. Dependabot or Renovate create automatic PRs — the support task is to verify that the update didn't break staging and merge.

Updates types: patch (1.2.3 → 1.2.4, only bugfix, safe), minor (1.2.0 → 1.3.0, new features with backward compatibility, usually safe), major (1.x → 2.x, breaking changes, require testing). Ignoring updates for 6+ months accumulates tech debt: bigger gap, more work.

WordPress is a separate story. The platform's popularity makes it a prime attack target. Outdated plugins are the #1 attack vector. Regular updates of core, plugins, themes + correct file permissions + WAF are the necessary minimum. Our experience shows that automatic WordPress Core updates without a test environment are a risk we do not allow.

How Does Monitoring Prevent Downtime?

Uptime monitoring. Basic HTTP check every minute. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Alert to Telegram or Slack on downtime — and notification upon recovery. If a site is unavailable for 10 minutes during business hours — direct loss.

Performance. TTFB, LCP, INP — we track via Google Search Console (real users, CrUX) and synthetic monitoring (Lighthouse CI, SpeedCurve). Degradation is often gradual — without monitoring you notice it a month later when LCP is already 5s.

Application errors. Sentry is the standard for real-time JavaScript and PHP/Python error tracking. Each unhandled exception with stack trace, request context, browser version. Especially important for errors users don't report — they just leave.

Database. Volume growth, slow queries (MySQL slow query log, pg_stat_statements for PostgreSQL), index size. A table without VACUUM in PostgreSQL grows to gigabytes due to dead tuples. Routine database maintenance is part of support.

Disk space and logs. Is logrotate configured? /var/log/nginx growing without limits and filling the disk — classic. Automatic rotation + alert at disk > 80%.

Why Are Backups Without Verification an Illusion?

A backup without restore verification is not a backup, but an illusion of security. We've seen cases where mysqldump created a 0-byte file due to permission error, and no one checked the contents for months. We guarantee all copies are restorable.

Backup scheme:

• Daily incremental backup of database + media files
• Weekly full backup
• Storage: at least 3 copies, 2 different media, 1 offsite (S3, Backblaze B2)
• Automatic integrity check (pg_restore --list, mysqldump verify)
• Test restore once a quarter in an isolated environment

Retention policy: 7 daily, 4 weekly, 3 monthly. S3 Lifecycle rules automate deletion.

SLA: What Does It Mean in Practice?

SLA (Service-Level Agreement) Wikipedia — specific commitments for response and resolution times:

SLA makes sense only with monitoring — otherwise you learn about problems from users, not systems. A broken button in a form can silently kill conversions for weeks.

Content Update Process

A developer should not be in the chain for editing text on a page. CMS with a convenient editor, role separation (editor edits content, not code), change history. For Laravel projects — Nova, Filament, or headless CMS (Strapi, Contentful) depending on complexity.

Preview before publishing, staged rollout for important changes. If editors work directly on prod — that's a risk.

Typical Situations We Resolve

Website hack: attack vector analysis, cleanup, security hardening (WAF, fail2ban, file permission restrictions). Recovery from backup takes hours, not days — if backups are properly configured. Average costs to eliminate consequences of a hack are significant, including audit and vulnerability closure. Regular support is much cheaper and prevents such incidents.

Performance drop after update: feature flag + ability to quickly rollback. Canary deployment — update 5% of traffic, check metrics, then 100%.

What's Included in the Support Package (Deliverables)

Upon signing the contract, you receive:

• Documentation: infrastructure diagram, access, recovery procedures
• Monitoring: uptime, performance, errors, logs — set up from day one
• Backup: daily/weekly copies with verification
• Dependency updates: monthly audit and update with testing
• SLA response: per priorities from the table above
• Reports: weekly dashboards, monthly review, quarterly tech plan
• Content editing support: editor training, permission setup

Contact us to choose a suitable plan and get an initial audit of your project.

How We Work: Stages

1. Onboarding (3–5 days): audit of current state, setup of monitoring and backups, infrastructure documentation.
2. Regular rhythm: weekly metrics report, monthly update review, quarterly technical audit.
3. Response: per SLA, with recording of cause and resolution time.
4. Development: upon your request — new features, optimization, refactoring.

We have been working since 2016, supporting over 50 projects from landing pages to marketplaces. Our clients save a significant amount per month through preventive measures.

Timelines and Cost

Setting up monitoring and backups: 3–5 days. Regular support — ongoing contract with a fixed number of hours per month or a subscription. Cost is calculated individually after audit. Get a consultation — we will evaluate your project in 1–2 days.

Comparison: Monitoring with Automatic Alerting vs Manual Checking

Automatic monitoring with Better Uptime responds to failures 10 times faster than manual checking.