Quem busca isso já decidiu migrar.
Ninguém sai do Magento 1 por vontade. Sai porque o PHP não atualiza mais, porque o módulo de pagamento parou de receber correção, porque a auditoria de segurança apontou a loja, ou porque o único desenvolvedor que conhecia os módulos foi embora. A decisão já está tomada quando a busca acontece. O que está em aberto é quem faz a travessia sem derrubar a operação.
A VTEX resolve a plataforma, mas cria três problemas que a loja Magento não tinha. O catálogo da VTEX separa produto de SKU e exige marca, árvore de categorias e campos de especificação criados antes de qualquer produto entrar. O OMS da VTEX não importa pedidos antigos: o histórico precisa de outra casa. E preço e estoque não vêm da loja antiga, vêm do ERP, que precisa falar com a VTEX desde o primeiro dia.
Por isso este par não é uma importação. É um projeto com três frentes paralelas: dados, integrações e endereços. Quem trata como importação descobre o problema do histórico no dia da virada.
O que do Magento 1 entrega, o que a VTEX aceita.
Magento 1, a origem
Loja de código aberto que dominou o varejo médio até 2020. Sem suporte oficial desde junho de 2020: sem correção de segurança, com PHP antigo e módulos abandonados. Fim do suporte oficial em junho de 2020.
- Catálogo em modelo EAV: atributos, conjuntos de atributos, produtos configuráveis e simples. A exportação nativa perde relações; usamos leitura direta do banco.
- Clientes e endereços com múltiplos endereços por cliente e grupos de cliente com preço diferente.
- Pedidos com histórico de status, faturas, envios e notas de crédito.
- Reescritas de URL na tabela própria do Magento, que é o mapa de 301 pronto.
- Módulos sob medida com regra de negócio que não aparece em lugar nenhum da documentação.
VTEX, o destino
Plataforma corporativa de comércio, por assinatura e receita, com loja, OMS e marketplace no mesmo contrato. Exige implantação formal e integração com ERP.
- Catálogo pela API, com produto e SKU separados, marca obrigatória, árvore de categorias e campos de especificação criados antes dos produtos.
- Preço e estoque entram por APIs próprias, separadas do catálogo, e costumam vir do ERP, não da loja antiga.
- Clientes no Master Data, sem senha; o acesso é por código enviado por e-mail.
- Pedidos antigos não entram no OMS: o histórico fica numa entidade própria do Master Data ou no ERP, consultável pelo cliente e pelo atendimento.
- Redirecionamentos por importação em lote no painel da loja.
Item por item, sem surpresa na virada.
| Item | Migra? | Como |
|---|---|---|
| Catálogo: produtos, SKUs, atributos e imagens | migra | Lidos direto do banco do Magento, não da exportação nativa. Produto configurável vira produto VTEX; cada simples vira SKU. Atributos viram campos de especificação criados antes. |
| Conjuntos de atributos e árvore de categorias | migra | Recriados na VTEX na mesma hierarquia. Categorias de marketing viram coleções. |
| Marcas | migra | Na VTEX marca é obrigatória. Produtos sem marca no Magento recebem uma marca genérica declarada e revisada com você. |
| Preço e estoque | parcial | Entram pelas APIs de preço e logística da VTEX, mas a fonte passa a ser o ERP. Fazemos a carga inicial a partir do Magento e a integração contínua a partir do ERP. |
| Grupos de cliente com preço diferente | parcial | Viram políticas comerciais e tabelas de preço na VTEX. Até três grupos no escopo típico. |
| Clientes e endereços | migra | Importados no Master Data, sem senha. O acesso na VTEX é por código enviado por e-mail, então ninguém precisa redefinir nada. |
| Pedidos antigos | parcial | Não entram no OMS da VTEX. Vão para uma entidade própria do Master Data, consultável pelo cliente em 'meus pedidos antigos' e pelo atendimento, ou ficam no ERP se ele já os tem. |
| Reescritas de URL do Magento | migra | A tabela de reescritas é o mapa de 301 pronto. Cada URL antiga, inclusive as duplicadas, aponta para a URL VTEX do mesmo produto ou categoria. |
| Módulos sob medida | não migra | Não rodam na VTEX. Cada um é inventariado e recebe destino: recurso nativo, app da VTEX, serviço nosso fora da plataforma, ou aposentado. |
| Tema | não migra | A loja VTEX é construída na implantação, no Store Framework. Entregamos o conteúdo das páginas institucionais e os textos de categoria. |
| Integração com o ERP | migra | Refeita contra as APIs da VTEX: catálogo, preço, estoque, pedidos e notas fiscais. É a frente mais longa do projeto. |
| Pagamento, antifraude e frete | não migra | Configurados na VTEX pela implantação. Levantamos as regras de frete do Magento para que nada fique de fora. |
| Avaliações, newsletter e cupons | parcial | Avaliações migram por app. Lista de newsletter vai para a ferramenta de e-mail. Cupons ativos são recriados. |
"Parcial" quer dizer que migra com perda declarada ou com trabalho manual no meio. "Não migra" quer dizer que é recriado no destino ou aposentado, sempre com a sua decisão registrada no inventário.
O prazo é do porte, não da vontade.
| Porte | Prazo | Preço |
|---|---|---|
| Até 5 mil SKUs, sem ERP | 8 semanas | R$ 45 a 60 mil |
| Até 20 mil SKUs, um ERP (típica) | 12 semanas | R$ 85 mil |
| Até 50 mil SKUs, ERP e marketplace | 16 a 20 semanas | R$ 110 a 160 mil |
| Multiloja, B2B ou vários países | 5 a 7 meses | a partir de R$ 180 mil |
Prazo em semanas corridas a partir do inventário aprovado. O que mais estica é o que depende de terceiros: ERP, gateway, equipamento, e a sua própria revisão do conteúdo.
R$ 85.000, e o que faz subir.
Referência para: Loja de até 20 mil SKUs e 300 mil pedidos, um ERP, uma loja, uma moeda. A implantação da VTEX e a assinatura da plataforma ficam fora.
Está dentro
- Auditoria do Magento: módulos, atributos, reescritas, integrações e tudo o que só existe no código.
- Modelagem do catálogo VTEX: especificações, marcas, árvore e políticas comerciais, feita antes da carga.
- Carga de catálogo, clientes e histórico de pedidos, com conferência automática de contagem e de amostras.
- Integração com o ERP refeita contra a VTEX, com monitoramento de fila e reprocessamento.
- Mapa de 301 a partir das reescritas do Magento e do Search Console, carregado e testado.
- Operação em paralelo até a virada e sessenta dias de acompanhamento depois dela.
Fica fora
- Implantação da loja VTEX em si: tema, checkout, pagamento, antifraude. Trabalhamos junto com quem implanta.
- Assinatura e taxa sobre receita da VTEX.
- Reescrita de descrições para SEO e fotografia.
- Conectores de marketplace além dos que a VTEX já oferece.
O que faz o preço subir, em ordem de frequência:
O que dá errado, e o que fazemos antes.
O histórico de pedidos descoberto tarde demais
O OMS da VTEX só recebe pedidos novos. Quem descobre isso na véspera deixa anos de histórico num backup. Mitigação: a casa do histórico é decidida na primeira semana, entre Master Data e ERP, e o cliente vê os pedidos antigos na conta desde o primeiro dia.
Catálogo EAV achatado errado
A exportação nativa do Magento perde a relação entre configurável e simples e mistura atributos de conjuntos diferentes. Mitigação: leitura direta das tabelas EAV, com relatório de produtos órfãos e atributos sem uso antes da carga.
Especificações criadas depois dos produtos
Na VTEX, campo de especificação criado depois não preenche o que já entrou. Mitigação: a modelagem do catálogo fecha e é aprovada antes da primeira carga.
ERP que falava com o Magento por módulo próprio
Muita integração de ERP com Magento 1 é um módulo PHP que ninguém documentou. Mitigação: a auditoria extrai as regras do módulo e cada uma recebe destino declarado na integração nova.
Preço vindo de dois lugares
Se a carga inicial vem do Magento e a integração contínua do ERP, divergências aparecem no primeiro dia. Mitigação: conferência de preço e estoque entre ERP, Magento e VTEX antes da virada, com lista de divergências resolvida por você.
URLs duplicadas e redirecionadas em cadeia
O Magento acumula reescritas: a mesma categoria com três endereços, cada um redirecionando para o outro. Mitigação: o mapa é achatado para que cada URL antiga chegue à nova num único salto.
Virada com duas verdades
Enquanto Magento e VTEX rodam em paralelo, pedidos entram nos dois. Mitigação: a virada é por domínio, com o Magento em modo catálogo, e os pedidos que entraram no Magento nas últimas horas são levados para o ERP à mão, com lista conferida.
Em paralelo, com volta garantida.
Módulos, atributos, reescritas, integrações, grupos de cliente e regras de frete. Sai o inventário com destino declarado para cada item e a decisão sobre o histórico.
Catálogo VTEX desenhado: especificações, marcas, árvore, políticas comerciais. Aprovado por você antes de qualquer carga.
Catálogo, clientes e histórico entram. A integração com o ERP é construída e roda em homologação com dados reais.
As duas lojas rodam. Mapa de 301 carregado e testado. Compras de teste de ponta a ponta com o ERP.
Domínio apontado para a VTEX, Magento em modo catálogo por 30 dias. Search Console, fila do ERP e pedidos conferidos toda semana.
Mailbiz Impulse: Magento e VTEX entre as 24 plataformas sincronizadas em tempo real
Origem e destino integrados em produçãoNão publicamos ainda uma migração Magento 1 → VTEX como caso. A experiência com as duas pontas vem do hub que construímos para a Mailbiz: 24 plataformas de loja sincronizando produtos, clientes e pedidos em tempo real com a ferramenta de e-mail, Magento e VTEX entre elas.
Foi nesse trabalho que aprendemos como o catálogo da VTEX separa produto de SKU, como o Master Data se comporta em carga e onde o Magento 1 esconde relações. A primeira migração deste par entra aqui como caso, com os números.
Os rótulos desta seção são três e dizem exatamente o que temos: migração feita, quando já entregamos este par; origem conhecida por dentro, quando construímos ou mantivemos sistemas na tecnologia de origem; destino em produção, quando operamos o destino em escala. Nunca um caso inventado.
O que sempre perguntam.
A VTEX ou o parceiro de implantação não fazem a migração?
A implantação constrói a loja nova: tema, checkout, pagamento. A migração de dados do Magento, a integração com o seu ERP e os redirecionamentos ficam com o lojista, e é esse o nosso trabalho. Trabalhamos junto com quem implanta, com cronograma único.
Os pedidos antigos somem?
Não, mas não entram no OMS da VTEX, que só aceita pedidos novos. Eles vão para uma entidade própria do Master Data, onde o cliente vê o histórico na conta e o atendimento consulta, ou ficam no ERP se ele já os guarda. A decisão é tomada na primeira semana.
Quanto tempo as duas lojas rodam juntas?
Em geral de duas a três semanas antes da virada, e o Magento fica no ar em modo catálogo por mais 30 dias depois. Nesse período qualquer problema permite voltar o domínio em minutos.
E os módulos que fizemos no Magento?
Não rodam na VTEX. Cada um é inventariado na auditoria e recebe um destino: recurso nativo da VTEX, app do ecossistema, serviço nosso rodando fora da plataforma, ou aposentadoria declarada. Nada some sem decisão sua.
Por que o prazo é de meses?
Porque a frente mais longa não é a carga de dados, é a integração com o ERP, que precisa ser construída, homologada com dados reais e observada sob carga antes da virada. Carga de catálogo leva dias; integração confiável leva semanas.
Vale considerar Magento 2 em vez de VTEX?
Se a loja depende de muita customização própria e tem time técnico, pode valer. Se o objetivo é tirar plataforma da sua responsabilidade e integrar marketplace e OMS, a VTEX costuma ganhar. A auditoria responde isso com os seus números, e o par Magento 1 → Magento 2 está em preparação nesta seção.
Comece pelo inventário.
Mande o endereço da loja ou uma descrição do sistema. Em até 24 horas úteis você recebe a confirmação da faixa de preço e prazo para o seu caso, sem compromisso. Se o par for outro, dizemos qual é.