Há uma frase que se ouve em quase todas as conversas sobre mudança de fornecedor de email: «sim, sabemos que devíamos mudar, mas é muito complicado».
Por trás dessa frase está um receio concreto e perfeitamente racional. O email é o sistema nervoso de uma organização. Se falhar meio dia, param faturas, param propostas, param respostas a clientes. Ninguém quer ser a pessoa que decidiu mexer nisso.
Este artigo não vai dizer que a migração é simples. Vai dizer exatamente o que pode correr mal, porque é que corre, e como se evita cada um dos casos. Quem trabalha nisto todos os dias sabe que a confiança não se ganha a minimizar riscos, ganha-se a nomeá-los.
Os sete problemas reais
1. Perder mensagens antigas. É o medo número um, e é legítimo. Uma migração mal conduzida pode copiar parcialmente o histórico e deixar de fora pastas inteiras, tipicamente as mais antigas ou as de maior dimensão.
2. Ficar sem receber durante a mudança. Existe um momento, na alteração dos registos de encaminhamento do domínio, em que parte do mundo já sabe do servidor novo e outra parte ainda aponta para o antigo. Mal gerido, esse intervalo produz mensagens perdidas ou devolvidas.
3. Descobrir tarde que faltava uma caixa. Contas de departamento, endereços de sistemas automáticos, caixas de um colaborador que saiu e que ainda recebe comunicações de clientes. Aparecem sempre, e raramente estão na lista inicial.
4. Deixar de fora os reencaminhamentos e as regras. Muitas organizações têm anos de regras acumuladas: faturas que vão para a contabilidade, formulários do site que caem numa caixa partilhada, alertas que seguem para o responsável de turno. Se essas regras não forem levantadas antes, descobrem-se pela ausência, e sempre no pior momento.
5. Os emails passarem a ir para spam depois da mudança. Mudar de servidor significa mudar a origem técnica das mensagens. Se as autorizações de envio do domínio não forem atualizadas ao mesmo tempo, o correio legítimo da empresa passa a ser tratado como suspeito pelos sistemas de destino.
6. Os calendários e contactos ficarem para trás. Muita gente trata a migração como sendo só de mensagens. Depois descobre que as marcações dos próximos seis meses e a lista de contactos da equipa não vieram.
7. Os dispositivos de cada pessoa deixarem de funcionar. O servidor mudou, mas o telemóvel de cada colaborador continua configurado para o antigo. Sem um plano para esta parte, o resultado é uma semana de chamadas ao apoio.
Como se faz sem sustos
Uma migração bem conduzida assenta num princípio que resolve metade dos problemas acima: nunca se apaga a origem.
Os dados são copiados, não movidos. Enquanto a cópia decorre, o serviço antigo continua a funcionar exatamente como sempre funcionou. Se algo falhar, não há nada a recuperar, porque nada foi destruído. Esta é a primeira pergunta a fazer a qualquer fornecedor, e a resposta deve ser imediata e sem rodeios.
A partir daí, o trabalho organiza-se em três fases.
Fase um: levantamento. Antes de copiar um único email, lista-se tudo. Todas as caixas, incluindo as que ninguém se lembra. Todos os aliases e reencaminhamentos. Todas as regras de filtragem relevantes. Todos os sistemas externos que enviam em nome do domínio, do software de faturação ao formulário do site. É a fase mais aborrecida e a que determina o sucesso de tudo o resto.
Fase dois: cópia em paralelo. As mensagens, pastas, calendários e contactos são copiados para a nova infraestrutura enquanto o serviço antigo continua ativo. A equipa não dá por nada. No fim desta fase, existem duas cópias completas, e a nova pode ser validada com calma.
Fase três: mudança de encaminhamento. Só quando a validação está feita se altera o encaminhamento do domínio para o novo servidor. A alteração propaga-se pela internet ao longo de algumas horas, e durante esse período as duas infraestruturas recebem correio. É por isso que o serviço antigo se mantém ativo mais alguns dias: para apanhar o que ainda chegar por lá.
Uma nota sobre o calendário desta fase. Faz-se preferencialmente fora do horário de maior atividade, e nunca na véspera de um fecho de contas, de um prazo processual ou de uma campanha. Não por risco técnico, mas porque qualquer imprevisto se gere melhor numa terça-feira de manhã do que numa sexta-feira à tarde.
A parte que cabe ao cliente
Há três coisas que nenhum fornecedor consegue fazer sozinho, e vale a pena saber disso à partida.
Decidir o que migra. Nem todo o histórico precisa de vir. Há organizações que trazem tudo, outras que trazem os últimos três anos e arquivam o resto. É uma decisão de negócio, não técnica.
Dar acesso ao domínio. A alteração de encaminhamento é feita onde o domínio está registado. Se ninguém na empresa souber onde isso é, ou quem tem as credenciais, esse é o primeiro problema a resolver. Acontece com mais frequência do que se imagina.
Avisar a equipa. Uma mensagem interna, dois dias antes, a explicar o que vai acontecer e o que cada pessoa vai precisar de fazer no seu telemóvel, poupa dezenas de interrupções.
As perguntas a fazer antes de assinar
- Os dados de origem são apagados em algum momento do processo? A resposta correta é não.
- O serviço atual continua a funcionar durante a migração? E até quando depois?
- O que está incluído: só mensagens, ou também calendários, contactos, aliases e regras?
- Quem atualiza as autorizações de envio do domínio, e quando?
- Quem acompanha a equipa na reconfiguração dos dispositivos?
- Qual é o plano se algo correr mal a meio?
Um fornecedor que responda a estas seis com clareza já demonstrou mais do que qualquer argumento comercial.
E quando não vale a pena migrar
Por honestidade, vale registar o inverso. Se a organização está a meio de uma fusão, de uma mudança de domínio ou de uma reestruturação profunda das equipas, faz sentido esperar. Migrar duas vezes é pior do que migrar tarde.
Fora disso, o adiamento costuma ter um custo silencioso: mais anos de um serviço que já não serve, mais dependência de uma configuração que ninguém domina, e um histórico cada vez maior para mover quando a decisão finalmente chegar.
A migração não é o momento de risco. O momento de risco é o dia em que o sistema atual falha e não havia plano nenhum.