Como migrar Magento Open Source ou Adobe Commerce para Mage-OS?

Migre quando a operação não depende de recursos exclusivos Adobe, o time ou parceiro sustenta patches e segurança, e a licença Adobe é material no TCO. Nesse perfil, Mage-OS remove a linha de licença mantendo o know-how Magento e a maior parte da stack.

Não migre quando ACCS, SLA comercial Adobe, B2B nativo, Live Search / Recommendations (Sensei), content staging ou outros recursos pagos entregam valor usado. Nesses casos, permanecer no Adobe Commerce — ou fazer upgrade na linha atual — costuma superar a troca de distribuição. Para a decisão de negócio e a matriz em três vias, leia Mage-OS vale a pena? e o comparativo Adobe Commerce vs Magento Open Source vs Mage-OS.

O que permanece: catálogo, pedidos, clientes e a maioria das extensões e temas Magento 2; o conhecimento Magento do time transfere. Como Mage-OS é upstream-compatível, a migração é troca de distribuição, não reescrita de plataforma.

O que muda: pacotes Composer apontam para o repositório Mage-OS (repo.mage-os.org / mirror.mage-os.org); recursos específicos Mage-OS e add-ons do Lab passam a existir; se a origem for Adobe Commerce, as exclusivas Adobe saem da stack e precisam ser recriadas, substituídas ou abandonadas.

Trate o checklist como gate go/no-go antes do trabalho em staging. Versão ≥ 2.4.8 é a baseline ideal para o script oficial de migração; Mage-OS 3.x espera PHP 8.3+ (preferência por 8.4/8.5). Inventarie cedo as extensões só-Adobe — essa lista define o esforço Commerce→Mage-OS mais do que o swap de Composer.

No Magento Open Source 2.4.8+, o script oficial de migração Mage-OS é o caminho padrão. Em caso direto (versão compatível, sem pacotes só-Adobe bloqueantes), o cutover via Composer costuma cair em cerca de 30 minutos e permanece reversível se você mantém o lock anterior e o backup.

Fluxo típico: apontar o Composer para repo.mage-os.org (ou o mirror público), rodar os passos oficiais em modo developer no staging, executar o plano de QA e então fazer cutover em produção. O detalhe operacional de comandos segue o Migration Guide Mage-OS e o runbook do parceiro — este guia descreve o fluxo, não cada flag de CLI.

Pense em Commerce → Mage-OS como Commerce → Open Source: os dados permanecem intactos; a camada paga Adobe não. Você perde B2B nativo, Live Search e Product Recommendations (Sensei), Commerce Intelligence, content staging, customer segments, gift cards e o canal de suporte/SLA Adobe.

O custo real é recriar o que de fato se usa versus a economia de licença. Extensões ou SaaS de substituição (busca, fluxos B2B, staging) podem comer parte do ganho de TCO. Adobe Commerce as a Cloud Service (ACCS) é outro perfil — SaaS multi-tenant gerenciado — e não é swap de Composer; trate como decisão de saída/arquitetura separada, não o mesmo caminho de on-prem ou Cloud PaaS.

Após o cutover, valide que os patches seguem a cadência Mage-OS e que a operação permanece na última branch suportada — Mage-OS só sustenta a última branch. Opcionalmente ative add-ons do Mage-OS Lab (hardening PCI DSS 4.0, tradução por IA, otimização de tema, async events) quando mapearem requisitos reais.

A escolha de frontend (Hyvä vs Luma) é independente do rótulo da distribuição. Observabilidade, QA de release e janela explícita de patch continuam no P&L: open source remove a linha de licença Adobe, não a responsabilidade operacional.

A Magecore não trata migração de distribuição como default. O Assessment de Precisão compara cenários em 12 meses — manter/otimizar, upgrade de versão na linha atual, Magento Open Source, Mage-OS ou outra plataforma quando o porte não cabe no ecossistema — e recomenda o caminho com números.

Se Magento Open Source ou Adobe Commerce para Mage-OS for o movimento certo, o assessment delimita gaps de feature, capacidade de sustentação e risco de cutover antes do trabalho de Composer. Agende um diagnóstico gratuito para decidir com P&L, não com folclore de migração.