PrestaShop 8 em fim de suporte: vale a pena migrar para a 9?

O que significa «suporte alargado» na prática

Desde julho de 2025, o PrestaShop 8 passou a suporte alargado. Não é o fim do suporte, mas também já não é uma manutenção completa: o ramo 8.x só recebe correções de bugs críticos, correções de segurança e as evoluções de hooks indispensáveis. As novas funcionalidades vão exclusivamente para a versão 9. O fim efetivo do suporte chegará com o lançamento do PrestaShop 10.

Por outras palavras, a pergunta «PrestaShop 8 em fim de suporte, é preciso migrar?» não se coloca em termos de avaria iminente. Coloca-se em termos de dívida técnica que se vai acumulando.

Os três factos técnicos que pesam mesmo

PHP. O PrestaShop 8 fica limitado ao PHP 8.1, cujo suporte de segurança oficial já terminou. O PrestaShop 9 aceita do PHP 8.1 ao 8.4. Mais cedo ou mais tarde, o seu alojamento vai retirar o PHP 8.1 do parque e deixa de ter escolha.

Symfony. O PrestaShop 8 assenta no Symfony 4.4, em fim de vida e sem backports de segurança. O PrestaShop 9 passou para o Symfony 6.4 LTS, com correções até ao final de 2026 e segurança até ao final de 2027. A equipa do PrestaShop indicou explicitamente que não está previsto qualquer backport para o ramo 8.x.

Node.js. A compilação dos temas na versão 9 exige Node 20 ou superior. É um pormenor que apanha desprevenidas as agências que ainda trabalham com um ambiente de build antigo.

O que se parte mesmo ao passar para a 9

A migração da 8 para a 9 não é uma simples subida de versão. Eis as ruturas que geram a carga de trabalho:

• Bibliotecas retiradas do core: o Swift Mailer substituído pelo Symfony Mailer, o Guzzle pelo Symfony HTTP Client, o League Tactician pelo Symfony Messenger. Qualquer módulo que declare use GuzzleHttp\... produz um erro fatal.
• Controladores de administração: o FrameworkBundleAdminController foi descontinuado a favor do PrestaShopAdminController. Os controladores passam a ser declarados como serviços, com injeção de dependências.
• Bundles eliminados: o sensio/framework-extra-bundle desaparece, pelo que as anotações de rota e de template deixam de funcionar.
• Autenticação do back-office totalmente assente no Symfony: os módulos de SSO ou de autenticação de dois fatores feitos em casa que dependiam do cookie histórico deixam de funcionar.
• Tema: o Hummingbird passa a ser o tema predefinido. Abandona o Bootstrap e parte as personalizações escritas para o Classic. O Classic continua a ser distribuído, o que permite ganhar tempo.

A grelha de decisão

Fique na 8 por agora se a loja está estável, o alojamento mantém o PHP 8.1, depende de módulos de terceiros cujo editor ainda não publicou uma versão compatível com a 9 e está em plena época alta. Nesse caso, aplique com rigor todas as correções de segurança 8.2.x.

Planeie a migração para os próximos 6 a 12 meses se a loja é um ativo central do negócio, se desenvolve novas funcionalidades com regularidade ou se o tema está muito personalizado. Quanto mais esperar, maior fica a distância entre o seu código e o core.

Pondere uma reconstrução em vez de uma migração se o tema é anterior a 2020, se acumula mais de dez overrides ou se mais de metade dos módulos de terceiros já não tem manutenção. Nesse cenário, migrar sai muitas vezes mais caro do que reconstruir de forma limpa, para um resultado pior.

Como orçamentar com honestidade

A auditoria prévia é a etapa mais rentável de todo o projeto. Consiste em responder a quatro perguntas:

1. Quantos módulos de terceiros existem e quantos têm versão compatível com a 9 publicada?
2. Quantos overrides há em override/ e continuam a ser úteis?
3. Quantos templates estão personalizados no tema e qual é a distância face ao tema-pai?
4. Que volume de código específico foi desenvolvido à medida?

Uma auditoria séria leva um a dois dias e transforma um orçamento aproximado num plano de trabalho fiável. Também permite descobrir que alguns overrides respondem a uma necessidade abandonada há muito tempo e que a migração vai ser mais leve do que se previa.

Nunca migre sem plano de recuo

Três precauções não negociáveis:

• um ambiente de pré-produção idêntico ao de produção, onde a migração completa corre antes de qualquer intervenção no site real;
• um plano de testes escrito que cubra o processo de compra, os pagamentos, as transportadoras, os e-mails transacionais e as exportações para a contabilidade;
• uma janela de mudança com cópia de segurança restaurável e um critério de falha decidido à partida.

Se a atualização já arrancou e ficou bloqueada, o nosso artigo sobre o Update Assistant trata os erros mais comuns. E se parte de uma versão anterior, o caminho é outro: veja a migração a partir do PrestaShop 1.6.

Auditar a sua loja

Fazemos a auditoria de compatibilidade, orçamentamos a migração e executamo-la com plano de recuo. Conheça a nossa abordagem na página de migração PrestaShop.