A pergunta que costuma aparecer primeiro é: “Em que dia vamos trocar o sistema?”. Dá para entender a pressa. A empresa contratou a solução, a equipe quer resolver os problemas antigos e ninguém deseja carregar dois ambientes por muito tempo. Só que marcar a data antes de conhecer o trabalho cria um compromisso que talvez a operação não consiga cumprir.
Uma migração mexe com faturamento, estoque, financeiro, acessos e pessoas. Copiar dados é uma parte dela. O projeto precisa mostrar como a empresa vai continuar trabalhando quando alguma coisa sair diferente do esperado.
Comece pelo termo de abertura
O documento de abertura, normalmente chamado de termo de abertura do projeto, registra por que a mudança existe, qual resultado se espera, quem patrocina a iniciativa e quem tem autoridade para conduzi-la. Também deve trazer limites iniciais, marcos, orçamento de referência, premissas e riscos conhecidos. Ele formaliza a autorização; não substitui o planejamento detalhado.
Em uma migração, eu colocaria ali perguntas bem diretas: quais empresas e unidades entram nesta etapa? Qual processo precisa funcionar no primeiro dia? Quanto tempo de indisponibilidade a operação aceita? Quem pode autorizar uma despesa adicional ou adiar a virada? É melhor descobrir uma divergência nessa conversa do que no domingo à noite, com a equipe esperando uma decisão.
Entenda a operação antes de desenhar o cronograma
Converse com quem vende, recebe mercadoria, concilia pagamentos e fecha o mês. Mapeie integrações, relatórios usados para decidir, personalizações, obrigações e rotinas que só acontecem em determinadas datas. Uma rotina pouco frequente pode ser justamente a que impede o fechamento.
Depois, transforme o escopo em entregas menores, com responsáveis e critérios de aceite. “Migrar o financeiro” é amplo demais. “Conferir títulos em aberto, vencimentos e saldos por empresa, com aprovação da área financeira” permite cobrar uma entrega concreta. Registre também o que fica fora: histórico antigo, unidades futuras e melhorias desejadas podem ter outra etapa.
O cronograma nasce dessas entregas, das dependências e da disponibilidade real das pessoas. Não adianta reservar homologação para a semana em que os usuários estarão no inventário. Inclua reuniões de decisão, aprovação das áreas, correções e um novo teste. Treinamento e preparação dos dados precisam aparecer como trabalho, com tempo reservado.
Deslize o gráfico para ver todas as colunas ou abra a tabela abaixo.
Ver dados do gráfico em tabela
| Frente de trabalho | Semanas do exemplo |
|---|---|
| Abertura e escopo | 1 |
| Mapeamento e dados | 1 a 3 |
| Parametrizações e integrações | 2 a 4 |
| Testes e conciliação | 4 a 6 |
| Treinamento por função | 5 a 6 |
| Ensaio e decisão | 7 |
| Virada e estabilização inicial | 8 |
No exemplo, algumas frentes se sobrepõem. Isso exige equipes disponíveis e versões controladas; não significa que tudo possa começar ao mesmo tempo. A parametrização depende de regras acordadas, e o treinamento final precisa acontecer em um ambiente suficientemente estável. As oito semanas do desenho não são uma recomendação de prazo para qualquer migração.
E o pior cenário? Ele precisa entrar na conversa
Sim, seria uma decisão frágil migrar sem avaliar situações graves e plausíveis: a carga ultrapassa a janela, uma integração deixa de responder, o saldo não fecha ou um processo crítico não funciona. Para cada risco relevante, registre causa, probabilidade, impacto, responsável, prevenção e resposta. A análise deve ser proporcional à operação, sem tentar adivinhar toda catástrofe possível.
O ajuste é este: gestão de projetos não estima tudo apenas pelo pior cenário. Uma técnica útil é trabalhar com três estimativas para uma atividade: otimista, mais provável e pessimista. Elas precisam ter premissas claras e vir de quem conhece o trabalho, dos ensaios e de dados disponíveis. Não são três números escolhidos para justificar uma data já prometida.
Imagine uma carga que poderia levar três dias em condições favoráveis, cinco no cenário mais provável e onze com dificuldades plausíveis. Pela média ponderada PERT, (3 + 4 × 5 + 11) ÷ 6, a estimativa seria aproximadamente 5,7 dias. Esse resultado é uma referência da atividade, não uma promessa nem um nível de confiança para o projeto inteiro.
Deslize o gráfico para ver todas as colunas ou abra a tabela abaixo.
Ver dados do gráfico em tabela
| Cenário | Duração ilustrativa |
|---|---|
| Otimista | 3 dias |
| Mais provável | 5 dias |
| Pessimista | 11 dias |
| Média ponderada PERT | 5,7 dias |
O prazo final também depende da sequência, do caminho crítico, da capacidade da equipe e dos riscos compartilhados entre atividades. As reservas devem ter motivo e critério de uso. Somar uma folga escondida em cada tarefa e depois acrescentar outra margem ao projeto pode contar o mesmo risco duas vezes. Reestime quando os ensaios trouxerem informação melhor.
Dados e parametrizações precisam de dono
Antes da carga, defina o que será levado: cadastros, estoques, saldos, títulos em aberto e histórico necessário. Combine uma regra para duplicidades, campos obrigatórios, códigos antigos e registros sem uso. Mantenha a origem preservada e trate cópias conforme as permissões e a sensibilidade dos dados. O ambiente de teste não deve virar um atalho para distribuir dados reais sem controle.
Documente a correspondência entre origem e destino. Quem era o fornecedor 123 no sistema antigo? Como ficará uma unidade de medida? O que acontece com um título parcialmente pago? Contar registros ajuda, mas não comprova sozinho que os valores e os vínculos estão corretos. Concilie totais e diferenças por empresa e período, e confira amostras relevantes com a área responsável.
Nas parametrizações, registre regras fiscais, permissões, condições comerciais, estoques, financeiro e integrações. Cada regra precisa de um responsável de negócio que confirme o comportamento esperado. Guarde a versão aprovada e as alterações posteriores. Uma opção marcada por tentativa pode afetar várias rotinas sem ficar evidente na tela onde foi configurada.
Teste o caminho completo, inclusive quando dá errado
Um teste útil acompanha uma operação de ponta a ponta: pedido, separação, faturamento, baixa de estoque, recebimento e conciliação, conforme a realidade da empresa. Inclua cancelamentos, devoluções, interrupções e repetição de mensagens. Uma integração pode funcionar uma vez e duplicar uma movimentação quando tenta novamente após uma falha.
Planeje carga, desempenho, acessos e recuperação. Em uma cópia isolada, execute o roteiro da virada e meça o tempo de cada passo. Teste também a restauração: ter um arquivo de backup é diferente de comprovar que ele pode recuperar o ambiente. Registre resultado, evidência, defeito encontrado, correção e novo teste.
A homologação precisa da participação de quem responde pelo processo. “A TI testou” não substitui o aceite do financeiro sobre os saldos nem o da operação sobre uma venda completa. Se ainda houver uma divergência, registre a gravidade e quem decide se ela impede a entrada em produção.
Treinamento é a pessoa conseguir trabalhar
Uma apresentação mostra o caminho; a prática revela onde a equipe trava. Separe os treinamentos por função e use situações próximas da rotina. Quem opera o caixa precisa conseguir vender e tratar uma exceção. Quem administra acessos precisa entender quais permissões conceder e quem aprova a concessão.
Reserve espaço para perguntas, materiais curtos de consulta e pessoas de referência em cada área. Verifique se os participantes conseguem executar as tarefas críticas, além de registrar presença. Ajuste as instruções quando uma regra mudar depois do treinamento. Não faz sentido ensinar uma configuração e colocar outra em produção sem avisar.
A virada precisa de roteiro e decisão
O plano de corte descreve a ordem das ações, os responsáveis, os horários e as verificações: interromper lançamentos quando necessário, gerar e validar a cópia de segurança, executar a carga final, conciliar, testar integrações e liberar a operação. Defina quem comunica cada marco e quem autoriza prosseguir ou parar. Combine esses critérios antes da janela, com as áreas de negócio e os fornecedores envolvidos.
Para autorizar a entrada, procure evidências: carga dentro da janela ensaiada; dados conciliados e diferenças tratadas; processos críticos aceitos; pessoas treinadas; suporte disponível; recuperação testada. Não existe uma lista universal que dispense análise, mas “chegou a data” não é um critério suficiente.
O plano de retorno merece o mesmo cuidado. Determine até que ponto é possível voltar, quanto tempo a recuperação leva e como tratar transações feitas depois da troca. Restaurar o sistema antigo sem reconciliar vendas e pagamentos novos pode criar outro problema. Em certos cenários, corrigir e avançar é mais seguro; essa possibilidade também precisa ser planejada e aprovada.
Depois da troca, o projeto ainda tem trabalho
Organize uma estabilização com responsáveis, canais de atendimento, prioridade dos incidentes e horários de acompanhamento. Acompanhe faturamento, integrações, conciliações e dificuldades dos usuários. Uma falha crítica exige resposta diferente de uma melhoria que pode esperar. Registre decisões e não transforme toda solicitação em urgência sem avaliar o impacto.
Combine os critérios para encerrar essa fase e transferir o atendimento para a rotina. Atualize a documentação e registre o que os ensaios não anteciparam. O objetivo é que a empresa consiga operar com segurança e saiba quem procurar quando precisar.
Planejar uma migração é tornar as decisões visíveis antes que a pressão apareça. O gerente de projeto não promete que nada vai dar errado. Ele organiza o trabalho para que riscos sejam discutidos, responsabilidades estejam claras e a autorização de seguir tenha fundamento.