eCommerce
Última Atualização:
Cátia Sá
Há uma recomendação na documentação oficial da Google sobre mudanças de endereços que quase toda a gente ignora, e que é a mais importante de todas.
A instrução é literal: muda uma coisa de cada vez. Se queres mudar de domínio, mudar de sistema de gestão de conteúdos e adotar um novo grafismo, faz cada uma dessas coisas em momentos separados e não todas ao mesmo tempo.
Ora, uma migração de plataforma de comércio eletrónico é, na prática, o oposto disto. Muda-se a plataforma, aproveita-se para redesenhar, aproveita-se para reorganizar as categorias, aproveita-se para reescrever os textos, e às vezes ainda se troca o domínio porque a marca também mudou. Tudo na mesma noite.
O problema não é cada mudança por si. É que, quando o tráfego cair, não vais conseguir saber qual delas o causou. Ficas com um sistema onde falharam 5 coisas em simultâneo, sem forma de isolar variáveis, e a única resposta honesta à pergunta "porque é que caímos" passa a ser um encolher de ombros caro.
A mesma documentação acrescenta 2 recomendações práticas que reforçam o ponto. Sugere calendarizar a mudança para um período de tráfego mais baixo, para que menos pessoas sejam afetadas por problemas e para que o servidor tenha mais folga. E avisa expressamente que é normal haver flutuação temporária de posições durante o processo, com sites de dimensão média a demorarem algumas semanas ou mais até que a maioria das páginas transite.
A sequência que reduz risco é aborrecida e funciona: migrar primeiro para a plataforma nova mantendo a estrutura de endereços e o aspeto tão parecidos quanto possível, estabilizar durante algumas semanas, e só depois redesenhar. Custa mais tempo. Poupa o segundo gráfico.
O inventário: não consegues redirecionar o que não sabes que existe
O trabalho começa por uma lista, e a qualidade dessa lista determina quase tudo o resto.
Precisas de todos os endereços que a loja antiga tem indexados, recebem tráfego ou têm ligações de fora. A documentação da Google aponta as fontes e vale seguir todas, porque nenhuma isolada é completa:
O mapa do site atual, porque é ali que estão os endereços que já submeteste para indexação.
Os registos do servidor e a ferramenta de analítica, para identificar os endereços que recebem tráfego real, incluindo os que não constam do mapa do site.
O relatório de ligações do Search Console, para as páginas com ligações internas e externas.
A exportação do próprio sistema de gestão de conteúdos, que costuma dar a listagem completa.
Há uma advertência explícita que vale ouro numa loja online: inclui imagens, vídeos e ficheiros descarregáveis. Uma fotografia de produto que está a receber tráfego da pesquisa de imagens é um endereço como outro qualquer e precisa de destino.
Na prática, as famílias de endereços que ficam esquecidas em quase todos os projetos são sempre as mesmas:
Páginas de categoria e subcategoria antigas, incluindo as que já não existem no novo menu mas continuam a receber visitas.
Páginas de filtro e de navegação por facetas, que costumam ter versões indexadas que ninguém sabia que existiam.
Páginas de paginação de listagens longas.
Produtos descontinuados que continuam a ter procura pelo nome.
Artigos de blog e páginas de apoio, muitas vezes o ativo orgânico mais valioso da loja.
Páginas institucionais com endereços herdados de uma migração anterior.
Uma regra que poupa muitas discussões: nenhum endereço sai do inventário sem uma decisão escrita ao lado. Ou tem destino, ou é eliminado deliberadamente. O que não pode acontecer é ficar sem menção, porque o que fica sem menção transforma-se numa página de erro no dia da mudança.
Na prática, isto vive numa folha de cálculo com colunas fixas: endereço antigo, visitas nos últimos 12 meses, ligações externas recebidas, endereço novo, tipo de resposta a devolver, responsável pela decisão e estado de verificação. Parece exagerado até ao dia em que alguém pergunta porque é que uma página deixou de existir e a folha responde em 5 segundos.
A ordem de trabalho também importa. Começa pelos endereços com mais visitas e mais ligações de fora, porque são os que concentram o risco, e trata a cauda longa depois. Numa loja com milhares de referências, uma minoria dos endereços costuma explicar a esmagadora maioria do tráfego, e é aí que a atenção humana tem de estar. O resto resolve-se com regras de correspondência por padrão, desde que alguém verifique uma amostra do resultado em vez de confiar na regra.
Com o inventário feito, cada endereço antigo recebe um destino. As regras técnicas são poucas e são todas importantes.
Usa redirecionamentos permanentes do lado do servidor. A recomendação é explícita: 301 ou 308, implementados no servidor. Os redirecionamentos do lado do cliente ficam como último recurso quando nenhuma opção de servidor é tecnicamente possível.
Evita cadeias. O Googlebot segue até 10 saltos numa cadeia de redirecionamentos, mas a recomendação é apontar diretamente ao destino final. Quando isso não for possível, mantém a cadeia curta, idealmente com não mais de 3 saltos e sempre abaixo de 5. Cadeias acrescentam latência para quem compra e nem todos os navegadores as suportam bem.
Não atires tudo para a página inicial. Redirecionar muitos endereços antigos para um destino único e irrelevante pode ser tratado como erro de página inexistente, além de confundir quem chega à procura de um produto e aterra numa montra genérica.
Devolve erro quando o conteúdo desapareceu mesmo. Se não estás a levar todo o conteúdo antigo, os endereços correspondentes devem devolver 404 ou 410 no site novo, e não um redirecionamento inventado.
Mantém os redirecionamentos no ar durante pelo menos 1 ano. Este prazo permite que todos os sinais sejam transferidos, incluindo a reatribuição de ligações de outros sites. Do ponto de vista de quem visita, a recomendação vai mais longe e sugere mantê-los indefinidamente.
Há um receio antigo que convém enterrar: a documentação afirma que redirecionamentos permanentes não causam perda de autoridade. O que causa perda é o endereço antigo não ter destino, ou ter um destino errado, ou o destino demorar 3 saltos a aparecer.
Convém também tratar os endereços novos com o mesmo cuidado. Cada um deve ter uma etiqueta canónica a apontar para si próprio, as anotações de idioma devem ser atualizadas para os endereços novos, e as ligações internas do site novo devem apontar diretamente para os destinos finais e nunca para os endereços antigos que depois redirecionam. Nada disto é opcional, e é matéria que se sobrepõe inteiramente ao trabalho de otimização orgânica de uma loja online.
Produtos que desaparecem: redirecionar, ou assumir que acabou
Este é o ponto onde as equipas costumam tomar a decisão preguiçosa, e a decisão preguiçosa custa dinheiro.
Um catálogo com anos tem sempre centenas de produtos que já não se vendem. A tentação é mandá-los todos para a página inicial ou para uma página de categoria genérica. É precisamente o comportamento que a documentação desaconselha.
A árvore de decisão correta tem 3 saídas:
Se existe um substituto direto, o produto novo que ocupa o mesmo lugar, redireciona para lá. Quem chegava à procura do antigo encontra o equivalente e a venda pode acontecer.
Se não há substituto direto mas há uma categoria com produtos comparáveis, redireciona para essa categoria específica. Não para a montra, para a prateleira certa.
Se não há nada parecido e o produto simplesmente deixou de fazer parte do negócio, devolve 410. É a resposta honesta e evita acumular redirecionamentos que não servem ninguém.
Esta lista trata-se com dados à frente, e não por instinto. Um produto descontinuado que continua a receber visitas mensais é um ativo. Um produto descontinuado sem visitas há 2 anos é um endereço que só existe para inflacionar o mapa do site.
A parte visível da migração é o catálogo: produtos, preços, fotografias. Essa quase sempre corre bem, porque é a que se vê. O que se perde é o que está em segundo plano.
Campos de otimização escritos à mão. Títulos e descrições que alguém redigiu produto a produto raramente sobrevivem a uma exportação, porque frequentemente vivem num campo próprio da plataforma antiga que não tem correspondente direto na nova. Ao chegar, ficam preenchidos automaticamente com o nome do produto, e o desempenho orgânico das fichas cai sem que ninguém perceba porquê.
Texto alternativo das imagens. Mesmo problema, com o agravante de afetar acessibilidade e pesquisa de imagens ao mesmo tempo.
Avaliações de clientes. É a perda mais dolorosa, porque é a única que não se pode refazer. Anos de prova social acumulada desaparecem se o serviço de avaliações estava integrado na plataforma antiga em vez de viver numa plataforma independente. Verifica isto antes de assinar seja o que for.
Estrutura de variantes. Tamanhos, cores e combinações são modeladas de forma diferente em cada plataforma. Uma variante mal migrada gera produtos duplicados, referências trocadas e encomendas erradas.
Regras fiscais e de arredondamento. Taxas de IVA por categoria de produto, isenções, regras para vendas intracomunitárias. Um erro aqui não se vê no site, vê-se na contabilidade.
Histórico de preços e promoções ativas. Campanhas programadas, códigos de desconto em circulação e preços de campanha em curso não migram sozinhos.
A conclusão prática é que a exportação e importação de um catálogo não é um passo técnico, é um projeto editorial. Cada campo que existia na loja antiga tem de ter um destino declarado na nova, e as fichas de produto devem ser auditadas por amostragem depois da importação, produto a produto, e não apenas contadas.
Faturação: a parte que nenhum guia internacional cobre
Aqui está o conjunto de passos que distingue uma migração feita neste país de uma migração feita a partir de um manual traduzido.
Se a plataforma nova é também o sistema que emite os teus documentos de faturação, mudar de plataforma implica obrigações fiscais concretas, e falhá-las produz documentos inválidos.
Segundo as orientações da Autoridade Tributária sobre séries e código único de documento, cada emitente tem de comunicar as séries que pretende utilizar, por cada tipo de documento e por cada meio de processamento, para obter o respetivo código de validação. A comunicação tem de ser feita antes do início de utilização da série, e o código de validação tem de estar associado à série no programa antes da emissão de qualquer documento. O meio de processamento só pode processar documentos numa série depois dessa associação estar feita.
Há 3 pormenores que transformam isto de burocracia em risco operacional real:
Um código de validação não pode ser reutilizado. Não é possível criar uma série nova com um identificador já usado no mesmo tipo de documento, nem reiniciar a numeração de uma série já utilizada. Mudar de plataforma implica, por isso, criar e comunicar séries novas.
Cada tipo de documento precisa do seu código. Faturas, notas de crédito, recibos, documentos de transporte. Usar o mesmo identificador de série em tipos diferentes exige códigos de validação distintos.
Os documentos emitidos em modo de teste também contam. Se vais experimentar a loja nova emitindo faturas de ensaio, essas têm de sair numa série específica, comunicada à Autoridade Tributária como série de formação. Emitir testes na série normal é criar um problema que depois não se apaga.
Há ainda a obrigação de manter atualizada, no Portal das Finanças, a informação sobre o programa de faturação em utilização, o que implica nova comunicação quando se troca de software. Confirma este passo e o respetivo momento com quem responde pela tua contabilidade, porque é feito antes da emissão do primeiro documento no sistema novo e não depois.
E há o ponto que quase toda a gente esquece quando desliga a plataforma antiga. O prazo geral de conservação de livros, registos e documentos de suporte é de 10 anos, e um parecer técnico da Ordem dos Contabilistas Certificados esclarece que essa obrigação se estende também às cópias de segurança dos dados de suporte aos programas de faturação e contabilidade. Traduzindo: cancelar a subscrição da plataforma antiga sem extrair e arquivar os dados fiscais é criar um problema com 10 anos de validade.
Antes de desligar seja o que for, extrai os ficheiros de auditoria, o histórico completo de documentos e as cópias de segurança, e guarda tudo com a mesma disciplina com que guardas o resto do arquivo contabilístico.
A base de clientes migra pior do que o catálogo, e as falhas manifestam-se sob a forma de vendas que não acontecem.
As palavras-passe não são guardadas, nem sequer cifradas. O que fica registado é um resumo criptográfico irreversível, calculado a partir da palavra-passe, que serve para confirmar que quem entra sabe a senha certa sem que a plataforma alguma vez a conheça. Plataformas diferentes calculam esse resumo por métodos diferentes, e é por isso que, em muitas migrações, os clientes existentes têm de definir nova palavra-passe. Nem sempre é inevitável: pergunta ao fornecedor novo se aceita importar os resumos da plataforma antiga, porque alguns aceitam e outros conseguem convertê-los na primeira vez que o cliente entra. Se a resposta for não, isto deixa de ser um detalhe técnico e passa a ser uma fricção colocada exatamente em cima de quem já comprava, que mal comunicada faz cair as taxas de acesso à conta durante meses.
O que fazer com isso é uma questão de comunicação e não de tecnologia. Avisar antes, explicar porquê, enviar a ligação de redefinição de forma proativa em vez de esperar que a pessoa tropece no problema no momento em que quer comprar.
Os pontos que exigem verificação explícita:
Pagamentos recorrentes e subscrições. Os identificadores que autorizam cobranças futuras estão associados ao processador de pagamentos e à loja antiga. Mudar de processador durante uma migração pode significar perder todas as autorizações e ter de pedir a cada cliente que volte a introduzir os dados. É a forma mais rápida de destruir receita recorrente e acontece com frequência desconcertante.
Histórico de encomendas. Migrar ou não migrar é uma decisão de negócio. Não migrar aumenta o volume de pedidos ao apoio ao cliente durante meses.
Programas de fidelização e saldos. Pontos acumulados, vales por usar, créditos de devolução. Perder isto gera conflito com os melhores clientes, precisamente os que mais notam.
Registos de consentimento. O consentimento para comunicações comerciais tem de acompanhar o contacto, com data e origem. Importar uma lista sem esses registos é ficar sem forma de demonstrar a licitude do tratamento.
Moradas e dados de faturação guardados. Um cliente que perde a morada guardada tem mais um passo a dar antes de comprar.
Velocidade: a loja nova é mais bonita e mais lenta
Acontece quase sempre, e por uma razão banal: o site novo tem um tema mais rico, mais tipos de letra, mais animações, mais aplicações instaladas e imagens que ainda ninguém otimizou.
As metas são públicas e não se discutem. Segundo a documentação da iniciativa Web Vitals, uma boa experiência exige que o maior elemento visível apareça em 2,5 segundos ou menos, que a resposta às interações fique em 200 milissegundos ou menos, e que a instabilidade visual do conteúdo se mantenha em 0,1 ou abaixo. E há um detalhe que muda a forma de medir: a avaliação faz-se no percentil 75 dos carregamentos reais, separando telemóvel de computador. Não é a média, e não é o teste que corres no teu portátil com fibra.
Daqui saem 2 obrigações práticas.
A primeira é medir a loja antiga antes de a desligar. Sem essa referência, quando alguém perguntar se o site novo está mais lento, a resposta será uma opinião. Com ela, é um número.
A segunda é tratar cada aplicação instalada como um custo. Módulos de conversa ao vivo, ferramentas de mapas de calor, pixéis de publicidade, avaliações, recomendações. Cada um acrescenta código que corre no navegador de quem compra, e o efeito acumulado costuma ser a diferença entre passar e não passar.
Boa parte da atenção nesta fase deve ir para o percurso de compra, porque é onde a lentidão custa dinheiro imediato e onde as regressões de desempenho se traduzem diretamente em carrinhos abandonados no checkout.
O ensaio: testar de verdade antes de mudar
O ambiente de pré-produção existe para uma coisa: encontrar problemas enquanto ainda são baratos. E há uma armadilha conhecida à saída dele.
Para impedir que a loja em construção seja indexada, bloqueia-se o acesso aos motores de pesquisa. É a atitude correta. O problema é que essa instrução tem de ser removida no momento da mudança, e a documentação da Google lista precisamente este esquecimento como o primeiro dos erros comuns em migrações. Uma loja nova que arranca bloqueada é invisível durante o tempo que demorar até alguém reparar.
A regra é preparar antecipadamente a lista exata do que tem de ser desativado no dia da mudança, e verificá-la depois de mudar, e não antes.
O ensaio funcional tem de ir muito além de clicar em páginas:
Completar uma compra real, do início ao fim, com cada método de pagamento ativo, incluindo os que quase ninguém usa.
Confirmar que a fatura é emitida corretamente, com os elementos obrigatórios e a série certa.
Testar cada regra de portes, incluindo os limites de peso, as zonas e as exceções, que é onde as regras de envio e logística costumam falhar em silêncio.
Fazer o percurso todo em telemóvel, que é onde a maioria das pessoas compra e onde a maioria dos erros de interface aparece.
Testar uma devolução e um reembolso, incluindo o que acontece ao stock.
Pedir a alguém de fora da equipa, que não conhece o projeto, para comprar sem instruções.
Este último ponto encontra mais problemas do que qualquer ferramenta automática, e custa uma tarde. Quem construiu a loja já não consegue vê-la com olhos limpos, porque conhece o caminho e salta inconscientemente os passos confusos.
Vale ainda definir, antes de começar o ensaio, o que é um problema bloqueante e o que é um problema tolerável. Sem esse critério escrito, chega-se à véspera com uma lista de 40 questões abertas e uma discussão emocional sobre se se avança ou não. Com ele, a decisão faz-se em minutos: bloqueia o que impede uma compra, o que emite um documento errado ou o que expõe dados; tolera o que é estético e se corrige na semana seguinte. É também o tipo de rigor operacional que se trabalha em detalhe na imersão CHECKMATE: eCommerce, onde a discussão sobre plataformas dá lugar à discussão sobre processos.
O dia da mudança: a sequência que reduz risco
A ordem importa, e a maior parte dos incidentes nasce de fazer as coisas pela ordem errada.
A sequência que funciona é esta:
Reduzir com antecedência o tempo de propagação dos registos de domínio, para que a mudança se propague depressa em vez de deixar uma parte do tráfego a ver o site antigo durante horas.
Ativar os redirecionamentos.
Remover os bloqueios de indexação e as instruções de não indexar que existiam no ambiente de testes.
Confirmar que as etiquetas canónicas apontam para os endereços novos e não para os antigos.
Submeter o novo mapa do site no Search Console.
Submeter um pedido de alteração de endereço apenas se houve mudança de domínio ou de subdomínio. Não é necessário para passagens de HTTP para HTTPS, para alternâncias entre versões com e sem "www", nem para mudanças de caminho dentro do mesmo domínio.
Testar uma amostra dos redirecionamentos com ferramentas de verificação, e não à confiança.
Há um ponto de capacidade que apanha muita gente desprevenida. A documentação avisa que, depois de uma migração, o Google passa a rastrear o site novo com mais intensidade do que o habitual, porque os rastreios do site antigo são redirecionados para o novo e somam-se ao rastreio normal. Uma loja que ficou com o alojamento no limite vai sentir isso exatamente na semana em que menos precisava.
Os primeiros 30 dias: o que medir e quando entrar em pânico
Depois da mudança começa a parte psicologicamente mais difícil, que é resistir à tentação de desfazer coisas.
O que se deve acompanhar, e por que ordem:
O relatório de mapas do site, submetendo tanto o antigo como o novo. A leitura correta é ver o número de páginas indexadas do mapa antigo a descer enquanto o do novo sobe. Os avisos sobre endereços que redirecionam no mapa antigo são normais e podem ser ignorados.
O relatório de cobertura de indexação, à procura de picos de erros inesperados.
Os registos do servidor, para apanhar endereços que devolvem códigos de erro que não deviam devolver.
A receita por canal, e não apenas as visitas. Uma quebra de tráfego orgânico com receita estável é um problema diferente de uma quebra de ambos.
As posições das consultas que traziam mais receita, e não a média de posições do site inteiro, que esconde tudo o que interessa.
Uma nota sobre comparações, porque é aqui que se tomam decisões erradas com dados corretos. Comparar as 4 semanas depois da mudança com as 4 semanas anteriores mistura o efeito da migração com a sazonalidade do negócio. A leitura menos enganadora é comparar com o mesmo período do ano anterior e, em paralelo, com um canal que não foi afetado pela migração. Se a receita direta e a de email caíram na mesma proporção, o problema não é a migração, é a procura.
Sobre expectativas, a documentação é clara: é normal haver flutuação temporária, e um site de dimensão pequena a média pode demorar algumas semanas até que a maioria das páginas transite, com sites maiores a demorarem mais. A migração acontece endereço a endereço, e considera-se completa apenas quando o Googlebot tiver visitado, pelo menos uma vez, cada endereço do site antigo e do novo.
A regra prática é não desfazer nada nas primeiras 2 semanas, exceto erros técnicos inequívocos. Reverter uma migração a meio deixa a loja num estado pior do que qualquer um dos 2 anteriores, porque passa a ter sinais contraditórios em circulação.
Cobrir o buraco enquanto o orgânico recupera
Se a quebra é esperada, faz sentido planeá-la em vez de a sofrer.
Durante as semanas de transição, os canais que não dependem da indexação passam a ser o amortecedor. A lista de contactos é o ativo que uma migração não consegue danificar, e é por isso que uma sequência bem preparada de comunicação por email para clientes de loja online vale mais nesta fase do que em qualquer outra do ano. Anunciar a loja nova, explicar a redefinição de palavra-passe e dar um motivo concreto para voltar resolve simultaneamente um problema de receita e um problema de suporte.
Reforçar temporariamente o investimento em anúncios também é defensável, desde que se saiba que é um seguro e não uma estratégia. É útil ter clareza sobre o equilíbrio entre tráfego orgânico e pago antes de aumentar orçamentos, porque a tentação de manter o reforço depois de a curva recuperar transforma uma medida temporária num custo permanente.
Há ainda um detalhe operacional que passa despercebido: as campanhas ativas continuam a apontar para os endereços antigos. Atualizar as páginas de destino dos anúncios, as ligações nos perfis das redes sociais e as assinaturas de correio eletrónico faz parte da mudança, e a documentação da Google enumera-o explicitamente entre as tarefas a executar logo após o arranque.
O que não migra e tem de ser reescrito
Há uma categoria inteira de conteúdo que ninguém trata porque não pertence a ninguém em particular.
As páginas de informação legal e comercial são o exemplo perfeito. Condições gerais de venda, informação pré-contratual, prazos de entrega, direito de livre resolução, garantias, tratamento de dados pessoais, gestão de consentimento de cookies. Numa migração, estas páginas são copiadas e coladas às pressas, ou pior, herdadas do modelo da plataforma nova, redigido para outro país e outro regime.
O resultado é uma loja que anuncia condições que não pratica, o que é simultaneamente um risco legal e uma fonte de reclamações. A política de devoluções merece atenção especial, porque é a que os clientes leem mais e a que mais depende de regras concretas que variam com o tipo de produto.
Na mesma categoria entram:
Os dados estruturados das fichas de produto, que informam preço, disponibilidade e avaliações. Se não forem replicados, os resultados enriquecidos desaparecem.
Os fluxos de correio eletrónico transacionais, que contêm ligações para endereços antigos e textos que já não correspondem ao processo.
Os catálogos enviados a comparadores e a plataformas de anúncios de produto, que continuam a apontar para endereços antigos e geram reprovações em massa se não forem atualizados.
As páginas de campanha criadas para promoções anteriores, que costumam ter ligações de fora e desaparecem sem que ninguém dê por isso.
Antes de tudo isto: será que precisas mesmo de migrar
Convém dizer isto sem rodeios, mesmo que contrarie o entusiasmo de quem já decidiu.
Uma parte substancial das migrações resolve um problema que não era da plataforma. A loja vende pouco, alguém conclui que a plataforma está desatualizada, e o projeto avança sem diagnóstico. Doze meses e um orçamento depois, a loja continua a vender pouco, agora com endereços diferentes.
Separa sintomas de causas antes de decidir:
Se o problema é velocidade, uma migração pode ajudar, mas otimizar imagens, reduzir aplicações instaladas e melhorar o alojamento resolve frequentemente o mesmo com uma fração do custo.
Se o problema é o aspeto, isso é tema, não plataforma.
Se o problema é a conversão, a resposta está no percurso de compra e nas fichas de produto, e muda-se sem trocar de sistema.
Se o problema é falta de visitas, uma plataforma nova não gera procura. Gera trabalho.
Se o problema é a plataforma não suportar algo estrutural que o negócio precisa mesmo, como um modelo de subscrições, uma integração central com o sistema de gestão, ou vendas em vários mercados com regras fiscais distintas, então sim, a migração é a resposta certa.
Só depois deste exercício faz sentido comparar opções, e a escolha de plataforma deve ser feita contra requisitos escritos, não contra demonstrações comerciais. Uma lista de requisitos com prioridades resolve mais do que qualquer tabela comparativa encontrada online, porque obriga a decidir o que é indispensável antes de alguém mostrar funcionalidades bonitas.
O calendário realista
Para terminar com números que ajudam a planear, sem prometer o que não se pode prometer.
O inventário e o mapa de redirecionamentos ocupam mais tempo do que qualquer pessoa estima, e é o trabalho que não pode ser comprimido. Numa loja com alguns milhares de referências, contar em semanas e não em dias.
A construção e configuração dependem da complexidade, mas raramente é aí que os projetos derrapam. Derrapam na validação: nos testes de compra, na conferência do catálogo, na verificação fiscal e na revisão das páginas legais.
Do lado da recuperação, a expectativa razoável é de algumas semanas para que a maioria das páginas transite, com variação em função da dimensão e da velocidade do servidor. Planear com uma janela de 3 meses até à estabilização completa evita decisões precipitadas ao fim de 10 dias.
E há uma decisão de calendário que vale mais do que todas: não migres em época alta. A tentação de ter a loja nova a tempo da campanha mais forte do ano é compreensível e é responsável por uma parte enorme dos desastres. Migra-se quando se pode dar ao luxo de correr mal.
O que torna uma migração perigosa não é a tecnologia. É que a maior parte do trabalho decisivo é invisível para quem paga, não aparece em nenhuma demonstração e não melhora nada no dia em que fica pronto. Ninguém entra na loja nova e comenta a qualidade do mapa de redirecionamentos. Mas é ele que decide se, daqui a 3 meses, estás a olhar para uma curva que recuperou ou para uma que assentou num patamar mais baixo e ali ficou. A boa notícia é que quase tudo o que corre mal é conhecido e evitável, e nada disto exige génio. Exige uma lista completa de endereços com destino declarado, uma mudança de cada vez, as séries de faturação comunicadas antes da primeira venda, os dados antigos arquivados antes de desligar o que quer que seja, e paciência suficiente para não desfazer nada na segunda semana. Faz esse trabalho aborrecido, e o gráfico que te vão mostrar daqui a um trimestre é o primeiro dos 2.
