Migrar de SFRA para PWA Kit sem Parar o E-commerce

Migrar de SFRA para PWA Kit não é uma decisão binária que se resolve num sprint de planejamento. É uma transição que, se malconduzida, coloca em risco receita, SEO e a sanidade do time — porque o e-commerce não pode parar de vender enquanto a arquitetura muda por baixo dele. A resposta prática não é "big bang", é convivência controlada entre monólito e headless por um período definido, com critérios claros de saída.

Este artigo não trata PWA Kit como sinônimo automático de performance melhor. Trata como uma mudança de arquitetura com custo real — de manutenção duplicada, de complexidade de roteamento e de risco de SEO — que só se justifica quando o ganho de performance e velocidade de entrega compensa esse custo. O objetivo aqui é dar ao Tech Lead argumentos e um plano para defender a decisão certa com dados, não com o hype em torno de headless.

Por que a migração "big bang" quase sempre falha

Trocar SFRA por PWA Kit de uma vez significa reescrever PDP, PLP, carrinho, checkout, busca, contas de cliente e todas as integrações (ERP, OMS, pagamento, frete) antes de colocar qualquer coisa em produção. Na prática, isso trava o roadmap de negócio por meses — e roadmap parado, para um Tech Lead sem poder de aumentar time, significa dívida técnica acumulando em paralelo enquanto ninguém entrega feature nova.

O risco não é só de prazo. É de regressão: um checkout novo, testado só em staging, entra em produção de uma vez e qualquer bug de edge case (cupom, split de pagamento, frete internacional) vira incidente em produção sem rota de fallback. Migração incremental existe justamente para eliminar esse "tudo ou nada".

Strangler pattern aplicado a SFCC

O strangler pattern — estrangular o monólito por partes, substituindo funcionalidades uma a uma até que o sistema antigo se torne redundante — é a estratégia mais defensável para SFRA → PWA Kit porque permite:

Validar PWA Kit em produção com tráfego real antes de migrar página crítica (checkout, por exemplo);
Reverter uma rota específica para SFRA sem reverter o projeto inteiro;
Distribuir o esforço de time ao longo de meses, em vez de concentrar risco numa janela de go-live única.

Na prática, isso significa que SFRA continua servindo parte do catálogo enquanto PWA Kit assume outra parte, com as duas stacks ativas simultaneamente por um período. É aqui que a maioria dos guias de migração patina: eles descrevem a arquitetura-alvo, mas não o estado intermediário — que é onde o Tech Lead realmente vive.

Guias técnicos da comunidade SFCC, como o Realm Split Guide for Migrating an SFCC Site (Rhino Inquisitor), documentam um raciocínio equivalente para migrações de realm: separar o que muda do que permanece estável, e tratar a transição como um projeto de arquitetura com fases nomeadas — não como um corte único. O mesmo princípio se aplica à migração de renderização (SFRA) para headless (PWA Kit): a unidade de migração não é "o site", é a rota.

Roteamento por página: a peça central da coexistência

O mecanismo que viabiliza o strangler pattern aqui é o roteamento por página (ou por padrão de URL) na camada de edge/CDN, decidindo, por request, se a resposta vem de SFRA ou de PWA Kit.

Padrões comuns:

Roteamento por path. /produto/* e /categoria/* vão para PWA Kit assim que estiverem prontos; /checkout/* e /minha-conta/* continuam em SFRA até serem migrados. Simples de implementar, mas exige disciplina para não deixar URLs "órfãs" — rotas que existem nos dois sistemas com respostas divergentes.

Roteamento por feature flag / cabeçalho. Útil para rollout gradual dentro da mesma rota (ex.: 10% do tráfego de PLP vai para PWA Kit), permitindo comparar performance e taxa de conversão lado a lado antes do corte definitivo.

Roteamento por domínio ou subpasta temporária. Menos elegante para o usuário final, mas reduz a complexidade de configuração de CDN no início do projeto — útil quando o time é pequeno e precisa priorizar velocidade de entrega sobre elegância arquitetural.

O trade-off aqui é direto: quanto mais granular o roteamento, mais controle sobre o risco, mas mais complexidade de configuração e mais superfície para bugs de roteamento — um problema silencioso que não aparece em teste funcional, só em produção sob carga.

Essa lógica não é só teoria de arquitetura. Em um projeto internacional para um varejista de saúde e beleza no Reino Unido e na Irlanda, conduzimos uma migração seguindo exatamente esse raciocínio: primeiro migramos o CMS para Amplience, construindo os componentes e as content pages, e configuramos a camada de firewall/edge do domínio para direcionar essas rotas de conteúdo especificamente para o PWA Kit — enquanto o restante da navegação continuava servido pelo site legado. As demais rotas foram incorporadas ao PWA Kit na sequência, em fases controladas do ponto de vista técnico, cada uma validada em produção antes de habilitar o corte de tráfego seguinte. O ganho prático desse faseamento não foi só técnico: deu ao time de negócio visibilidade de progresso real, sem exigir um go-live único de alto risco.

Sessão e autenticação: o ponto onde a coexistência quebra

Um dos erros mais comuns em migrações incrementais é subestimar a sincronização de sessão entre SFRA e PWA Kit. SFRA usa sessão de servidor tradicional; PWA Kit consome SLAS (Shopper Login and API Access Service) via token. Se o usuário navega entre uma rota SFRA e uma rota PWA Kit no mesmo carrinho de compras, ele não pode perceber que trocou de sistema — carrinho, login e preferências precisam persistir.

Esse é exatamente o tipo de problema técnico que documentação de comunidade sobre SLAS Session Sync in SFRA and SiteGenesis (Rhino Inquisitor) endereça: como manter token e sessão coerentes entre o mundo de sessão de servidor e o mundo de token headless. Ignorar esse ponto no planejamento é a causa mais comum de "logout fantasma" e carrinho perdido durante períodos de coexistência — e é o tipo de bug que corrói a confiança do negócio na migração, mesmo quando a arquitetura está correta.

SEO durante a transição: o que não pode quebrar

SEO é o ativo mais frágil numa migração de renderização, porque Google reindexa com atraso e penaliza inconsistência. Pontos não negociáveis:

Redirects 301 antes do corte de tráfego, não depois. Se a URL muda de estrutura entre SFRA e PWA Kit, o redirect precisa existir no momento em que a rota antiga para de responder — nunca depois.
Canonical tags e meta tags consistentes entre as duas stacks durante a coexistência. Se SFRA e PWA Kit geram title/description diferentes para a mesma entidade de produto em fases distintas do rollout, o Google trata como conteúdo instável e isso afeta ranking. Regras de meta tag em SFCC têm nuances documentadas (Rhino Inquisitor, Deep Dive into SFCC Meta Tag Rules) que valem revisão antes de replicar em PWA Kit.
Sitemap único e atualizado, refletindo qual sistema serve cada URL no momento — não dois sitemaps concorrentes.
Core Web Vitals monitorados por rota, não só globalmente. É comum PWA Kit melhorar LCP na PLP e piorar CLS no PDP por causa de hidratação mal ajustada — a métrica agregada esconde isso.

O erro mais caro aqui não é técnico, é de sequência: migrar a rota antes de validar que o SEO técnico da nova stack está no mesmo nível (ou melhor) que o do monólito. Perder ranking numa categoria de alto tráfego durante a transição custa mais, em receita, do que qualquer ganho de performance no médio prazo.

O custo real da manutenção duplicada

Durante a coexistência, o time mantém duas stacks: bugs de catálogo, promoções e integrações precisam ser corrigidos em ambos os lugares até que a migração da rota correspondente seja concluída. Para um Tech Lead sem poder de aumentar headcount, isso é o trade-off mais concreto do projeto inteiro.

Formas de mitigar sem fingir que o custo não existe:

Priorizar migração por impacto de manutenção, não só por valor de negócio — migrar primeiro as rotas que mais geram chamado de suporte ou hotfix no monólito reduz o custo duplicado mais rápido.
Congelar feature nova em SFRA para rotas já roteadas parcialmente para PWA Kit, evitando que o time desenvolva duas vezes a mesma regra de negócio.
Definir prazo de desligamento por fase, não um prazo único de "fim do projeto". Cada rota migrada deve ter uma data de desativação do código SFRA correspondente — sem isso, "manutenção temporária" vira permanente.

Como decidir a ordem de migração

A ordem correta normalmente segue risco decrescente, não valor de negócio decrescente:

PLP e páginas de conteúdo — menor complexidade de estado, maior ganho de performance percebido, bom para validar a stack PWA Kit em produção com risco controlado.
PDP — mais complexa (variantes, disponibilidade, personalização), mas ainda sem transação financeira.
Carrinho e conta do cliente — exige a sincronização de sessão discutida acima.
Checkout — migrar por último, e só depois que SLAS, sessão e integrações de pagamento estiverem validadas em produção nas fases anteriores.

Migrar checkout primeiro, por ser a página mais visada em discussões de headless, é o erro clássico de quem otimiza para a demo e não para o risco operacional.

Conclusão

Migrar de SFRA para PWA Kit é uma decisão de arquitetura com trade-offs reais — performance contra prazo, ganho de UX contra custo de manutenção duplicada, velocidade de rollout contra risco de SEO. O strangler pattern com roteamento por página, sincronização de sessão bem planejada e disciplina de SEO durante a transição não eliminam esse custo, mas o tornam visível, sequenciado e reversível — que é exatamente o que separa uma migração defensável de uma aposta.