Por que migrei WordPress para Odoo — e o que essa troca realmente custou

Oitenta dólares, plugin anual e a preguiça de mais uma gambiarra

O gasto não era só hospedagem. Tradução, SEO, tema, ferramenta de IA: cada um com renovação. O servidor multilíngue puxava o banco. 80 dólares por mês, no meu recorte, não quebrava o projeto se você comparasse com o que o site trazia. Quebrava a paciência. Todo ano a mesma lista: renovar, achar substituto, atualizar, torcer para o plugin de tradução não deitar a MariaDB.

Eu gosto de WordPress limpo. WooCommerce me dava gastura. Site de cliente em page builder, menos ainda. Precisava de curso online e queria loja. Empilhar mais plugin em cima de `wp_posts` era a definição de gambiarra. Passei anos olhando o Ghost — rápido, Node, 100 ms no discurso de marketing, e curto demais para o que eu publicava. Olhei o Strapi. Headless pediria programação que eu não ia manter. Eu não sou programador.

Odoo apareceu numa busca sem roteiro. Python. Preço com hospedagem deles, na tela que eu mostrei em novembro de 2025: 38 reais num plano, 57 no custom. Aquilo incluía o Odoo Online. Para site de empresa ou de cliente, eu disse que era a melhor porta. Para o meu blog de SEO programático, o Online não ia servir. Eu ainda não sabia o tamanho dessa frase.

ERP usado como CMS: e-mail, WhatsApp, curso, loja e Studio

Odoo nasceu para inventário, funcionário, estoque, CRM. Website é módulo, não o centro. O que me puxou foi o resto no mesmo sistema: automação de e-mail, automação de WhatsApp, IA nativa, social. Módulo de e-learning. Loja com estoque e dropshipping. Open source. A vitrine paga com hospedagem existe. A Community é gratuita se você autohospeda. A on-premise da linha paga traz add-ons como o Odoo Studio e a IA embutida. Eu acabei na on-premise. Explico o porquê no próximo bloco.

Um login segura vários sites. No WordPress eu tinha várias instalações. Multisite existe e nunca é a mesma coisa. No Odoo, blog posts de sites diferentes podem cair na mesma tabela de blog; modelo personalizado — o dicionário, o módulo de jogos — fica em tabela própria. PostgreSQL aguenta isso com outra cara que MariaDB no `wp_posts`. Imagem no WordPress é post. Custom post é post. Custom field, se você quiser tabela separada, pedia plugin que no meu caso estava ano sem atualizar.

Studio: campo novo no arrastar. Coluna nova no banco. Significado, definição, origem, classificação, campo semântico, formalidade, palavra composta. Eu montei o dicionário assim, sem Advanced Custom Fields, sem GenerateBlocks, sem shortcode. SQL no próprio back, módulo de chat, pesquisa, WhatsApp. A loja de aplicativos instala na hora. Isso é o argumento de “pare de renovar plugin”: a funcionalidade já está no ERP ou se instala como módulo Python, não como PHP solto.

Odoo Online quebrou nas URLs; Cloudpepper entrou na fatura

A intenção era largar os 80 dólares e usar o servidor do Odoo. Dez mil visitas por dia, no meu juízo, o Online aguentava. O obstáculo foi URL. Odoo Online força um subdiretório de blog e coloca identificador nas slugs. Eu tinha mais de 30 mil páginas indexadas. Mudar o padrão da rota era jogar esse índice fora ou viver de redirecionamento eterno. Por isso não usei o Online.

Python, para quem vinha de PHP e Nginx, foi a segunda dor. Git, deploy, processo: eu não tinha o músculo. Gastei com plataforma barata, 4 ou 5 dólares por mês, para gerenciar isso. Não rolou. Fui para o Cloudpepper, 30 dólares no mês, só o gerenciamento. O servidor continua à parte. A fatura não caiu para zero. Em parte, subiu em complexidade. O Odoo, mesmo em Python, me pareceu mais leve que o WordPress naquela máquina. Antes: 32 GB de RAM, 16 núcleos compartilhados, MariaDB em 90% por causa do plugin de tradução. Depois: tabela de blog é tabela de blog. Custom model é outra tabela. A leitura não carrega string de HTML de vinte idiomas para montar um parágrafo.

Confira preço de Cloudpepper, Odoo Online e Community no dia em que você for contratar. Eu estou cravando o que estava na tela em novembro de 2025, não uma tabela eterna. Community continua sendo a porta sem licença Enterprise. On-premise com Studio foi o meu recorte porque eu precisava de campo personalizado e de URL que o Online não deixava.

Tradução nativa em JSONB, e o n8n que raspou o site antigo

Odoo traduz nativo. Sem TranslatePress, sem WPML, sem string solta por parágrafo. A dor da migração foi não querer pagar API de tradução de novo. Eu já tinha as versões no ar. Montei um workflow no n8n que raspou as páginas e gravou as traduções direto no banco do Odoo. Não foi um clique. O Odoo guarda os idiomas na mesma linha, na mesma coluna de conteúdo, em JSONB — eu falei “Johnson B” no vídeo, binário de JSON. Um objeto com `pt_BR`, `en_US`, o HTML de cada um.

Isso é bom na leitura: o banco pega o idioma pedido e para. Não monta a página a partir de mil strings. É ruim para quem, como eu, mexia no MySQL na unha, copiando célula. Quase ninguém faz isso. Eu fazia. Importar o restante do WordPress, porém, foi o trecho fácil: CSV do acervo, tela de importação, mapear coluna para campo, milhares de posts ou custom posts em segundos. Campo personalizado incluso, se você já criou o modelo no Studio.

Clique no post no back e o Odoo abre o front. Dá para editar no próprio site, com blocos — menos blocos que o Gutenberg, e o tema também se edita ali, estilo do item, imagem de capa. SEO nativo, sem plugin anual. Quem quer ficar no back, fica: ficha do post, metadado, o dicionário com todos os campos visíveis em formulário. Os dois caminhos existem. Eu uso os dois.

1. Exporte WordPress em CSV (post, custom post, campo que você ainda precisa).
2. Crie o modelo no Studio antes de importar, para a coluna existir.
3. Mapeie cada coluna do CSV no importador nativo; rode numa base de teste.
4. Se já houver tradução no ar, raspe a URL antiga e grave no JSONB — não dispare API de modelo “para ver”.
5. Não use Odoo Online se você não puder perder o padrão de slug atual.

View XML, tag t, ação de servidor e um mês até ficar fluente

Layout de página no Odoo é view XML. Parece HTML com outro sotaque. A tag `t` executa Python no front: se o campo existe, mostra o bloco; se não, some. Variável, filtro, soma. No WordPress eu fazia isso com shortcode e filtro PHP. Aqui o ChatGPT escreveu a view do dicionário em minutos e a página nasceu com os campos do Studio, sem GenerateBlocks. Herança de view: você injeta um pedaço em outro modelo, antes, depois, no meio. Visibilidade por site, por grupo, condição, direito de acesso.

Ação de servidor não é a mesma coisa que ação de janela nem que ação agendada. Você cria a ação, aponta para o modelo (publicação de blog, por exemplo), cola Python limitado — a ajuda do Odoo lista o que não pode; avançado vira módulo. Ou pula o código e usa o bloco “atualizar com IA”: escolhe o campo destino, o campo que entra como variável no texto, manda traduzir, preencher vazio, gerar título. E-mail, SMS, WhatsApp, atividade de CRM saem da mesma família. O produto é back-office. Front é consequência.

Levei cerca de um mês para acostumar e migrar. Sobrou slugification: eu ainda queria a URL igual à do WordPress em sites que não tinham vindo. Dá para editar quase tudo; o que não dá, módulo. eLearning traz curso, fórum, relatório, sem plugin de LMS. Login com política de senha nativa, sem Frankenstein. Python e fatia menor de mercado, na minha conta, significam menos bot genérico do que WordPress. Isso é opinião, não auditoria. A plataforma tem mais de vinte anos, é open source, tem canal oficial e suporte. Eu gostei de trabalhar nela. Este vídeo não cobre o mapa inteiro. Cobre a migração, as dores e o motivo de eu ter saído do CMS em que eu era fluente.

Na sequência

1. Some plugin anual + servidor + horas de atualização antes de chamar o WordPress de “já pago”.
2. Abra uma instância de teste e tente publicar um post com a URL que o Google já conhece.
3. Se o Online mudar a slug, planeje on-premise ou aceite redirecionamento em massa.
4. Crie o modelo no Studio antes do CSV, não depois.
5. Migre tradução existente por arquivo ou scrape; não pague a mesma API duas vezes sem necessidade.
6. Reserve semanas, não um fim de semana, para view XML e direito de acesso.

Onde isso quebra