Portugal tem uma história particular com o Magento. Desde meados da década de 2010, marcas de moda, electrónica e distribuição especializada construíram as suas lojas sobre esta plataforma porque oferecia algo que nenhum outro sistema open source dava: um modelo de catálogo sério, atributos configuráveis e uma capacidade real de suportar operações de vários milhões de euros por ano. Hoje, em 2026, a pergunta que chega à nossa mesa com frequência é diferente. Ainda faz sentido continuar a investir em Adobe Commerce ou chegou a hora de migrar para WooCommerce headless?
A resposta honesta não é um sim absoluto. É um sim condicionado, e este artigo explica exactamente quando o é e quando não é.
TL;DR
- O Magento Open Source continua a ser código mantido, mas o ramo 2.4 LTS atingiu o seu fim de suporte oficial e o Adobe Commerce concentra agora os investimentos sérios.
- O Adobe Commerce 2.4.7 foi publicado em abril de 2024 como novo ramo de manutenção; as licenças e a complexidade operacional continuam a pesar.
- O WooCommerce, com uma quota estimada de 8 a 10 por cento do comércio electrónico mundial segundo o BuiltWith e o W3Techs, amadureceu o suficiente para sustentar retalho médio.
- A combinação de WooCommerce com um frontend Astro 5 ou Next.js 15 sobre Cloudflare Workers entrega tempos de resposta competitivos sem a carga operacional do Magento.
- Nem todo o Magento deve migrar: B2B com fluxos específicos da Adobe, catálogos acima de 100.000 SKU activos e arquitecturas multi-website complexas costumam ficar onde estão.
Porque o Magento foi dominante em Portugal
Para entender a decisão de 2026 é preciso olhar para a história. Quando o Magento 1 surgiu como referência open source para comércio electrónico, Portugal estava a reconstruir o seu mercado online depois da crise financeira e do resgate. As marcas que sobreviveram precisavam de uma plataforma capaz de gerir catálogos amplos, várias divisas, configurações de IVA em taxa normal, intermédia e reduzida, e a complexidade logística de servir tanto o continente como as regiões autónomas. O Magento oferecia exactamente isso. Empresas integradoras do Porto, Lisboa e Braga construíram equipas especializadas, e em muitos casos essas equipas continuam activas.
Em maio de 2018, a Adobe adquiriu o Magento por aproximadamente 1.680 milhões de dólares. A operação não foi uma surpresa para quem observava o sector: a Adobe precisava de uma peça de comércio na sua Experience Cloud e o Magento trazia um ecossistema maduro. A consequência, contudo, marcou o rumo. A plataforma reorganizou-se em dois produtos: Magento Open Source, gratuita e sustentada pela comunidade, e Adobe Commerce, a edição paga com funcionalidades empresariais como B2B, segmentação avançada e Page Builder melhorado.
Depois chegou a data que muitos retalhistas ainda recordam com desconforto. A 30 de junho de 2020, o Magento 1 atingiu o seu fim de vida. Dezenas de lojas portuguesas tiveram de migrar para Magento 2 com prazos apertados, orçamentos imprevistos e uma sensação clara de que o controlo sobre a plataforma se tinha deslocado. Essa migração forçada de 2020 é, em muitos casos, a origem do cansaço que hoje leva a avaliar alternativas.
O que mudou entre 2020 e 2025
Em cinco anos, o panorama mexeu-se mais do que parece. Três mudanças concretas importam.
Primeiro, o custo sustentado do Adobe Commerce. A licença anual continua a ser calculada sobre receitas brutas e, somada à infraestrutura especializada que a plataforma exige, representa uma rubrica fixa que muitos retalhistas médios questionam quando a comparam com as suas margens reais. Numa economia onde a margem do retalho é frequentemente apertada, essa conta pesa.
Segundo, a complexidade acumulada do ecossistema Magento. Os módulos de terceiros, as personalizações do checkout, os conectores com ERPs locais como o PHC ou o Primavera BSS, e as integrações com os métodos de pagamento portugueses como o Multibanco, o MB Way e a rede SIBS formam uma camada que, ao fim de vários anos, poucas equipas conseguem mexer sem dor. A dívida técnica acumulada torna-se um argumento por si só.
Terceiro, o amadurecimento das alternativas. O WooCommerce, que em 2018 era considerado apto apenas para lojas pequenas, incorporou o HPOS para escalar encomendas, melhorias sérias na API REST e um ecossistema de extensões que cobre a maioria dos fluxos de retalho médio. A sua quota global, estimada pelo BuiltWith e pelo W3Techs entre 8 e 10 por cento do comércio electrónico mundial, é difícil de ignorar. E, sobretudo, chegou a era headless: separar o frontend do backend permite que a velocidade e a experiência já não dependam do peso tradicional de um monólito PHP.
Quando migrar faz sentido
A decisão de migrar não deve basear-se em moda nem em pressão comercial. Há cinco critérios concretos que, quando se cumprem pelo menos três, justificam ponderar a mudança.
O primeiro é o catálogo. Se a sua loja gere menos de 50.000 SKU activos, com atributos relativamente estáveis e categorias que não mudam todos os dias, o WooCommerce funciona sem esforço extraordinário. A barreira prática onde a curva de complexidade se inclina costuma situar-se à volta desse número.
O segundo é a equipa. Se manter o seu Magento exige depender de um ou dois integradores externos porque dentro da empresa ninguém domina a plataforma, está numa situação frágil. O WooCommerce vive sobre WordPress, e a oferta de talento WordPress em Portugal é substancialmente maior. A rastreabilidade humana do projecto melhora com a migração, e para lojas que trabalham com programadores de WooCommerce essa transição é bem mais previsível.
O terceiro é a velocidade percebida. Se os seus tempos de carregamento em telemóvel estão acima de três segundos em LCP apesar das optimizações de Varnish e FPM, a arquitectura tradicional do Magento chegou ao tecto para o seu caso. Um frontend headless em Astro ou Next.js, servido a partir de Cloudflare Workers, entrega HTML em milissegundos e liberta a experiência do peso do backend.
O quarto é o roteiro. Se o seu plano a três anos inclui experiências de cliente mais ricas, integração com aplicações móveis próprias, conteúdo editorial e comércio misturados, ou experimentação rápida com landing pages, o modelo headless dá uma liberdade que o frontend tradicional do Magento não concede.
O quinto é o custo real. Não o custo de licença isolado, mas a soma de licença, alojamento especializado, contratos de manutenção e horas de programador. Quando esse total anual ultrapassa amplamente o que uma alternativa headless equivalente custaria em operação, o ROI de migrar deixa de ser teórico.
Quando o Magento deve ficar
Aqui vem a parte que não se diz tanto. Nem toda a loja Magento precisa de migrar. Há quatro situações onde recomendamos honestamente ficar.
A primeira é B2B com funções específicas do Adobe Commerce. Se usa a sério Company Accounts, Shared Catalogs, Quick Order ou Requisition Lists, replicar tudo isso em WooCommerce significa construir muito à mão. O esforço pode não compensar.
A segunda são os catálogos grandes. Acima de 100.000 SKU activos, especialmente se os seus atributos são numerosos e os seus filtros frontais são intensivos, o Magento continua a ser a opção mais natural. O WooCommerce pode lá chegar, mas exige integrações com motores de pesquisa externos e um nível de optimização que já equivale, em complexidade, a manter Magento.
A terceira é a arquitectura multi-website com segmentação avançada por país, idioma e moeda partilhando um único stock central. O Magento tem essa camada desenhada de raiz; o WooCommerce simula-a com plugins, e a diferença nota-se.
A quarta é o momento do negócio. Se a sua loja está em plena época alta, em processo de financiamento ou numa transição organizativa, não é a altura. Uma migração de comércio mal calibrada pode custar vários meses de receita. A janela correcta existe, mas é preciso saber escolhê-la.
A rota de migração para WooCommerce headless
Quando a decisão é migrar, a rota tem quatro fases bem diferenciadas. Falamos de migração real, não de redesenhar templates.
A primeira fase é a auditoria. Inventário completo do catálogo, atributos, conjuntos de atributos, categorias, produtos configuráveis, produtos agrupados, regras de catálogo, regras de carrinho, métodos de envio, gateways de pagamento integrados, zonas fiscais, customer groups e qualquer personalização do checkout. Esta fase produz o mapa de tudo o que existe e a decisão explícita sobre o que se conserva, o que se simplifica e o que se elimina.
A segunda fase é o data mapping. Cada entidade do Magento traduz-se para uma entidade do WooCommerce. Produtos simples e configuráveis mapeiam-se para produtos simples e variáveis. Os atributos personalizados passam a taxonomias ou meta. Os conjuntos de atributos, que no Magento são uma peça estrutural, achatam-se no WooCommerce porque não existem enquanto tal. Aqui já começa a aparecer a dívida implícita do modelo de origem. Se vem de uma migração anterior a partir de outra plataforma, o padrão é semelhante ao que descrevemos no guia de migração de Shopify para WooCommerce.
A terceira fase são os scripts de migração. Recomendamos sempre escrever código próprio em vez de depender cegamente de plugins genéricos. Um script controlado lê a base de dados do Magento, transforma os dados e escreve no WooCommerce respeitando as relações, os SKU canónicos e as encomendas históricas. As encomendas não se descartam: importam-se com os seus estados originais, as suas linhas de produtos, os seus impostos calculados e as suas referências ao cliente. Se decidir não migrar encomendas abaixo de certa antiguidade, essa decisão documenta-se e comunica-se.
A quarta fase é a estratégia de SEO e de redireccionamentos. O Magento gera URLs com padrões específicos, e qualquer mudança sem redireccionamento 301 mata posições ganhas ao longo de anos. Cada URL antiga mapeia para uma nova URL no WooCommerce, e mantém-se um ficheiro de redireccionamentos gerido ao nível do Cloudflare ou dos Workers. É a fase menos visível e a que mais tráfego orgânico salva.
O que normalmente corre mal
Vimos muitas migrações, próprias e alheias. Cinco erros repetem-se com desconforto.
Mapeamento de SKU. No Magento é habitual que os produtos configuráveis tenham um SKU pai e os produtos simples associados tenham SKU filhos. O WooCommerce trabalha com produtos variáveis e variações, onde a lógica do SKU não é idêntica. Quem não se senta a mapear esta correspondência com calma acaba com duplicados, produtos órfãos e relatórios de stock que mentem.
Migração de hashes de cliente. As palavras-passe no Magento são armazenadas com um algoritmo diferente do WordPress. Não podem ser traduzidas. As opções são duas: forçar um reset em massa, comunicado por email com antecedência, ou implementar uma ponte que valide a palavra-passe contra o hash original no primeiro login e a reescreva em formato WordPress nativo. Ambas são válidas, mas exigem uma decisão consciente.
Tradução de conjuntos de atributos. Como já dissemos, os attribute sets do Magento não existem no WooCommerce. Quem não achatar essa estrutura com critério acaba com produtos a que faltam atributos-chave no frontend, e com filtros que devolvem resultados incompletos. O achatamento pede uma análise séria do modelo de catálogo, não um script automático.
Facturação certificada e obrigações fiscais. Este é o ponto onde o retalho português tem de parar. Em Portugal, a facturação está sujeita a software certificado pela Autoridade Tributária, com numeração sequencial, código ATCUD, QR Code obrigatório e a exportação mensal do ficheiro SAF-T (PT). O WooCommerce nativo não emite facturas certificadas, e nenhuma migração séria pode ignorar isto: é preciso integrar uma solução de facturação certificada (o próprio ERP ou um serviço homologado) e garantir que as taxas de IVA a 23 por cento, 13 por cento e 6 por cento, além das taxas próprias dos Açores e da Madeira, são aplicadas correctamente por zona. Mais de uma migração cobrou IVA errado durante semanas antes de alguém reparar, e nesse caso o problema não é apenas técnico, é de conformidade legal.
Preservação de URL rewrites. O Magento mantém uma tabela de url_rewrite que é, na prática, o histórico vivo de SEO da loja. Uma migração que ignora esta tabela perde redireccionamentos internos acumulados ao longo de anos. É preciso extraí-la, normalizá-la e traduzi-la para redireccionamentos geridos no novo ambiente.
O que oferecemos na WPPoland
Na WPPoland construímos há anos arquitecturas headless para clientes com expectativas reais sobre desempenho e manutenção. A nossa abordagem parte sempre da auditoria honesta, não da proposta de migração por defeito. Se o seu Magento deve ficar, dizemo-lo. Se a migração faz sentido, desenhamos a rota completa, executamos os scripts, definimos a estratégia de redireccionamentos e deixamos um frontend Astro ou Next.js servido a partir de Cloudflare Workers que entrega LCP abaixo do segundo em telemóvel. A oferta detalhada está na nossa página pilar de WordPress headless.
Trabalhamos com equipas séniores que entendem o contexto português: métodos de pagamento locais como o Multibanco e o MB Way, ERPs habituais como o Primavera e o PHC, particularidades fiscais como o SAF-T e a facturação certificada, e a cultura concreta do retalho nacional. O objectivo não é vender uma migração, é garantir que, se ela acontece, corre bem à primeira.
Onde encaixa este artigo
Este texto faz parte de um cluster maior sobre WordPress empresarial e comércio electrónico moderno. Se vai planear uma migração, interessa-lhe também perceber que modelo de renderização encaixa com o seu volume e a sua volatilidade de catálogo antes de escolher a arquitectura.
A pergunta não é se o Magento Adobe Commerce continua a ser uma plataforma séria. É. A pergunta é se continua a ser a plataforma adequada para o seu negócio em 2026. Para uma parte do retalho português, a resposta honesta aponta para WooCommerce headless. Para outra parte, não. A única coisa que não recomendamos é decidir sem ter medido.
