Migrar do Magento para o BigCommerce

O Magento Open Source e a Adobe Commerce dão controlo total sobre o código, o alojamento e o checkout, ao custo de ter de gerir essa infraestrutura por conta própria: patches de segurança de PHP e do Magento, alojamento em servidor ou cloud, e conformidade PCI para o checkout que aloja. O BigCommerce, como plataforma SaaS gerida, retira ao cliente o alojamento, a conformidade PCI e a aplicação de patches de segurança da plataforma, em troca de trabalhar dentro das limitações da sua plataforma em vez de código arbitrário.

Um motivo frequente é o mesmo que empurra comerciantes para o Shopify: o custo de manter um programador ou uma agência a cargo de uma instância Magento deixa de fazer sentido quando o crescimento da loja já não justifica esse esforço, sobretudo em lojas ainda a correr uma instância Magento 2 sem patches ou presas ao Magento 1, já fora do fim de vida.

A estrutura de catálogo EAV (Entity-Attribute-Value) do Magento permite definir atributos personalizados praticamente arbitrários por tipo de produto. O modelo de produtos do BigCommerce é mais estruturado do que o do Magento, mas geralmente mais flexível em termos de variantes do que plataformas SaaS concorrentes — suporta nativamente um número maior de combinações de variantes de produto, além de campos personalizados e modificadores de produto para atributos fora da estrutura de variantes. Ainda assim, isso significa que os conjuntos de atributos do Magento precisam de ser mapeados de forma deliberada para as opções de variante e os campos personalizados do BigCommerce, e não copiados atributo a atributo.

A árvore de categorias do Magento permite aninhamento arbitrário com definições de apresentação por store view, e um produto pode pertencer a várias categorias em simultâneo. As categorias do BigCommerce estão mais próximas de uma árvore tradicional do que o modelo de coleções planas do Shopify, o que torna a migração de uma estrutura de categorias Magento profundamente aninhada algo mais direta — mas ainda vale a pena rever e simplificar nos casos em que a estrutura do Magento cresceu organicamente ao longo dos anos, em vez de ter sido desenhada.

As URL keys e os rewrites do Magento são totalmente configuráveis por store view. O BigCommerce, ao contrário do Shopify, permite caminhos de URL personalizados para produtos, categorias e páginas, sem impor um prefixo obrigatório como /products/ ou /collections/ — o que pode facilitar a preservação de uma estrutura de URLs Magento existente. Isso não elimina a necessidade de um plano de redirecionamentos: qualquer URL que mude continua a precisar de um redirecionamento 301 explícito, e o exercício de auditar cada URL indexada do Magento contra o seu novo equivalente no BigCommerce tem de acontecer de qualquer forma, para evitar uma queda de posicionamento após a migração.

O ecossistema de extensões do Magento e a sua capacidade de personalizar o checkout e os fluxos de administração em código não têm equivalente direto no BigCommerce — o BigCommerce usa um marketplace de apps, além das suas próprias APIs e da personalização de loja Stencil/Catalyst para lógica personalizada. Cada extensão Magento ativa exige uma decisão explícita durante a avaliação: uma app equivalente no BigCommerce, uma construção personalizada sobre as APIs do BigCommerce, ou a confirmação de que já não é necessária. O modelo multi-site/multi-loja do Magento também precisa de ser mapeado para as capacidades multi-loja do BigCommerce, que funcionam de forma diferente por baixo, mesmo quando o resultado final parece semelhante.