Migração do PrestaShop da Hestia para a DirectAdmin
Uma migração do PrestaShop não precisa significar mover toda a stack. Neste caso, movi o backend de uma configuração antiga da Hestia para um novo host baseado em DirectAdmin em uma única noite. O frontend permaneceu em sua plataforma existente. Os serviços de Newsletter e CRM permaneceram onde estavam. O escopo foi mais restrito: fazer com que o novo backend lidasse com APIs REST, cache e cron para um sistema de ecommerce multiloja.
O trabalho ativo levou cerca de três a quatro horas. A transferência de arquivos foi a parte fácil. O verdadeiro trabalho foi provar que o roteamento, Redis, cron, invalidação de cache e respostas de API específicas da loja ainda funcionavam após a mudança.
O que eu movi na Migração do PrestaShop
O backend foi instalado em um plano de hospedagem compartilhada moderna com armazenamento NVMe, CPU alocada e RAM alocada. O painel de hospedagem relatou o pacote e a cota de disco esperados.
Eu não movi tudo, e isso foi intencional.
Movido:
Mantido no lugar:
Eu prefiro esse tipo de migração estreita do PrestaShop porque reduz o ruído. Se você mover o frontend, a stack de marketing e o backend ao mesmo tempo, cria variáveis demais. Aqui, eu queria validar um sistema de negócios claro.
O Roteamento Foi o Primeiro Problema
O PrestaShop roda como um backend multiloja. Isso significa que um backend deve responder corretamente para duas lojas. No host antigo, as regras do painel e o comportamento existente da URL ocultavam parte da complexidade. No novo host, as chamadas REST tinham que preservar o contexto da loja antes que o PrestaShop redirecionasse ou canonicalizasse a solicitação.
A correção foi rotear corretamente as chamadas REST com prefixo da loja:
Isso parece menor no papel. Na prática, este é o tipo de detalhe que faz uma migração parecer quebrada, mesmo quando os arquivos, o banco de dados e o DNS estão corretos. No meu trabalho, verifico o roteamento antes de culpar o PHP, o Redis ou o banco de dados.
Redis Ajudou, mas a Limpeza de Cache Importava Mais
O Redis foi habilitado através de um socket Unix:
text /home/account/.redis/redis.sock
O PrestaShop então usou o Redis como backend de cache. As respostas da API melhoraram, mas o cache só importa se for limpo no momento certo.
O Back Office é a fonte da verdade. Quando alguém altera um preço, descrição de produto, bloco do PageBuilder, categoria ou campanha no PrestaShop, a API do frontend deve servir dados atualizados. Habilitar o cache sozinho não é suficiente. Eu também tive que conectar a limpeza de cache aos hooks relevantes do PrestaShop.
Verifiquei o comportamento diretamente:
Essa é a diferença entre "o cache está habilitado" e "o cache pode ser confiável". No ecommerce, essa diferença importa imediatamente.
Jobs de Cron Precisaram de Filtragem Cuidadosa
A primeira verificação de cron da Hestia encontrou jobs que pertenciam a outro serviço, não ao backend do PrestaShop. Esses jobs não pertenciam ao novo host porque esse serviço não fazia parte desta migração.
Os jobs relevantes do PrestaShop estavam no antigo servidor Hestia em produção:
Eu não migrei um job de CRM suspenso. Também pulei os jobs internos do sistema da Hestia. A DirectAdmin tem seu próprio fluxo de manutenção e backup, então copiar detritos do painel apenas teria criado confusão.
Um job de dump de banco de dados foi primeiro mapeado como um dump de desenvolvimento cauteloso. Eu o removi assim que confirmei que o painel de hospedagem já lidava com os backups. Duplicar fluxos de backup cria ruído, a menos que haja uma razão clara de recuperação.
Resultados de Desempenho da Movimentação do Backend
Testei o mesmo endpoint REST público 12 vezes por loja:
text /rest/pagebuilder/placements
Aqui estavam os resultados:
| Ambiente | Média Loja A | Média Loja B |
|---|---|---|
| --- | ---: | ---: |
| Hestia antigo em produção | 0.500s | 0.420s |
| Hestia de Staging | 0.305s | 0.302s |
| Novo host DirectAdmin | 0.267s | 0.220s |
O servidor de staging era um servidor de referência simples e respondia consistentemente. O novo host ainda respondeu mais rápido para ambas as lojas.
O novo host também mostrou uma média de carga do servidor mais alta, em torno de 10-13. O SSH expôs mais threads de CPU no host físico do que a alocação da conta, então esse número não foi alarmante por si só. A conta parecia tranquila: o Redis estava quase ocioso, os workers PHP não estavam驱动ando a CPU e o banco de dados tinha baixa carga de consultas ativas quando verifiquei.
É por isso que trato a média de carga com cuidado em hospedagem compartilhada. Ela reflete o host, não apenas uma conta. Se seu provedor vende um plano com especificações claras de CPU e RAM, ainda ajuda perguntar como esses limites são aplicados através do CloudLinux ou LVE.
Meu Fluxo de Trabalho com IA para a Migração
Usei o Codex como agente operacional para SSH, trabalho com API da DirectAdmin, verificações de servidor, alterações no crontab, testes de tempo e trabalho de override do PrestaShop.
Para revisão, uso meu fluxo de trabalho aberto ai-collab-bridge. A ideia é simples: uma IA implementa a mudança, então outra IA recebe um pacote de revisão com o diff, o contexto e perguntas focadas. O Claude Code pode então revisar o trabalho como um segundo leitor técnico, em vez de reagir a um resumo solto.
Isso importa em uma migração do PrestaShop porque há muitas pequenas decisões:
A IA ajuda quando tem que mostrar suas verificações. "Funciona" não é suficiente. Uma execução de migração útil mostra comandos, códigos de status, comportamento do cache, estado do cron e as partes que foram intencionalmente não movidas.
Lições que Tirei Desta Migração
Não copie o comportamento do painel cegamente. A Hestia e a DirectAdmin resolvem a manutenção de hospedagem de forma diferente. O cron do painel Hestia não pertence à DirectAdmin.
Mantenha a migração do backend estreita. Se o frontend já roda em outro lugar, movê-lo apenas adiciona risco.
Verifique o cache do ponto de vista do back office. Mudanças no ecommerce acontecem através de edições de preço, estoque, cópia e campanha. Cache que falha em limpar torna-se um problema de negócios.
Meça o mesmo endpoint repetidamente. Uma solicitação `curl` diz pouco. Doze execuções por loja me deram um sinal muito mais claro.
Não hardcode senhas de banco de dados em scripts. Leia da configuração existente da aplicação quando necessário e deixe o painel de hospedagem cuidar dos backups.
Resultado
Após a mudança, o backend respondeu mais rápido do que tanto o antigo servidor em produção quanto a referência de staging em meus testes. Redis e LiteSpeed ajudaram. A API da DirectAdmin foi suficiente para as configurações de painel que eu precisava. A memória do OPcache acabou sendo uma configuração de nível de host, então isso pertence ao suporte de hospedagem, não ao código do app.
O principal resultado não foi um TTFB menor. O resultado importante foi que o backend ainda se comportava como um backend de ecommerce: o back office possui os dados, a API responde por loja, o cache é limpo nas alterações e o cron executa apenas os jobs que pertencem ao novo host.
FAQ
Quanto tempo a migração levou?
A migração ativa do backend levou cerca de três a quatro horas. Com testes de tempo, inventário de cron, verificação de cache e notas de suporte, o trabalho ficou mais próximo de quatro a cinco horas.
Por que você não moveu tudo?
O frontend já rodava em outro lugar. A automação de newsletter e o CRM tinham seus próprios ambientes. Uma movimentação estreita do backend reduziu o risco.
Por que o Redis foi importante?
O Redis melhorou a velocidade do cache do backend, mas o valor real veio quando a limpeza de cache foi conectada aos hooks do PrestaShop. Sem isso, as alterações do back office podem falhar em chegar à API.
Por que a média de carga é difícil de ler em hospedagem compartilhada?
A média de carga frequentemente mostra toda a fila do host, não apenas sua conta. Nesta migração, a conta parecia tranquila enquanto o host mostrava carga mais alta. É por isso que os limites do CloudLinux ou LVE devem ser confirmados pelo suporte.
Por que usar IA em uma migração de servidor?
A IA é útil quando trabalha com evidências: leituras de config, testes de tempo, comparação de cron, verificações de API e mudanças documentadas. A revisão por pares através de um fluxo de trabalho aberto facilita deixar outro modelo inspecionar os riscos.