Dia do Cutover: O Checklist que Previne Desastres

O dia do cutover não é hora de improvisar. Todo CRM que correu mal tinha a mesma causa raiz: nenhum plano escrito. As equipes que executam cutovers limpos seguem um checklist, têm um gatilho de rollback definido antes do primeiro registro ser importado, e comunicam à equipe de vendas em cada estágio.

Aqui está como um cutover ruim se parece: uma empresa de 200 pessoas migrou do Salesforce para um novo CRM em uma tarde de sexta-feira. A importação correu bem. Na hora 6, a equipe de vendas estava bloqueada em ambos os sistemas porque o freeze de dados não havia sido comunicado corretamente. Três itens ausentes do checklist causaram isso: nenhum procedimento de freeze de dados, nenhuma comunicação enviada aos reps com antecedência, nenhum DRI (Directly Responsible Individual) nomeado para a janela de cutover. A equipe fez rollback no fim de semana e remarcou para três semanas depois.

Este guia é o plano que você executa. Imprima-o. Leia-o na noite anterior. Atribua um responsável a cada item.

T-Menos 48 Horas: Checklist Pré-Cutover

Checklist Pré-Cutover (10 itens)

Se qualquer um destes 10 itens estiver incompleto a T-menos 48 horas, adie o cutover. Um atraso de uma semana é melhor do que um go-live fracassado.

T-Menos 2 Horas: Freeze de Dados

O freeze de dados é uma das partes mais mal gerenciadas de uma migração. A maioria das equipes o anuncia muito tarde, não o aplica e acaba com a origem e o destino divergindo durante a janela de importação.

Por que importa: Se um rep cria um novo contato no CRM de origem às 9h15 e sua importação ocorre das 9h ao meio-dia, esse contato não estará no destino. O rep pensa que seus dados foram perdidos. Essa desconfiança no novo sistema começa no primeiro dia e é difícil de desfazer.

Como aplicá-lo:

Envie uma mensagem no Slack/Teams 2 horas antes da janela de freeze com o horário exato: "A entrada de dados no [CRM de origem] será bloqueada das 10h às 14h hoje."
Mude as permissões de usuário do CRM de origem para somente leitura para todos os usuários não administradores durante a janela de importação. Este é o único método de aplicação confiável.
Para o Salesforce: configurações de Perfil — remover permissões de Criar/Editar para todos os objetos, exceto para usuários administradores.
Para o HubSpot: não há um modo "somente leitura" único — o mais próximo é remover temporariamente todos os usuários não administradores da conta.

O que fazer com negócios que chegam durante a janela de freeze: Isso vai acontecer. Um rep recebe um lead inbound às 10h30 durante o freeze. A resposta: anote, não insira no sistema de origem e insira diretamente no destino após o go-live.

A janela de freeze deve ser de pelo menos 1 hora antes do início da importação. Não comece a importar no momento em que o freeze entrar em vigor — dê um buffer de uma hora para que qualquer entrada de dados de última hora seja concluída.

Horas 1–3: A Execução da Importação

Você está seguindo o documento de sequência de importação. Nenhuma improvisação.

Sequência de Importação

Execute as importações nesta ordem exata. Cada etapa depende da anterior para resolução de relacionamento:

Empresas / Contas — Sem dependências. Execute primeiro.
Contatos — Depende das Empresas (para associação de empresa). Verifique se a contagem de registros de empresa corresponde antes de prosseguir.
Negócios / Oportunidades — Depende dos Contatos (para associação de contato). Verifique se a contagem de registros de contato corresponde antes de prosseguir.
Atividades (ligações, e-mails, notas, tarefas) — Depende de Contatos e Negócios. Execute por último.
Objetos Customizados — Se aplicável. Execute após todos os objetos padrão.

Entre cada etapa:

Verifique o log de importação para erros antes de prosseguir para o próximo objeto
Anote a contagem de registros e compare com o esperado
Verifique 3 registros manualmente para confirmar que a importação mais recente correu corretamente

O que observar no log de importação:

Erros de conversão de tipo (valor de texto em campo de número)
Falhas de campo obrigatório (registros ignorados porque um campo obrigatório era nulo)
Falhas de resolução de relacionamento (contato importado mas associação de empresa falhou)
Detecção de duplicata (se o destino tem regras de dedup, alguns registros podem ser bloqueados)
Erros de limitação de taxa ou tempo limite (importações grandes podem atingir limites de API; pause e retome se necessário)

Para grandes conjuntos de dados (50.000+ registros): Execute a importação em lotes de 10.000–15.000 registros por lote. Isso fornece um ponto de recuperação se a importação falhar no meio e facilita o QA — você pode verificar cada lote antes de executar o próximo.

Não inicie o QA até que a importação esteja totalmente concluída. É tentador começar a verificar registros durante a execução da importação. Espere. Dados parciais são enganosos.

Horas 3–4: QA de Go-Live

Esta é sua verificação final antes de acionar o sistema. Percorra a lista de 15 verificações sistematicamente. Cada verificação tem um veredicto de aprovado/reprovado.

Checklist de QA de Go-Live (15 verificações)

Verificações de contagem de registros:

Total de contatos no destino = contagem esperada (±0,5%)
Total de empresas no destino = contagem esperada (±0,5%)
Total de negócios no destino = contagem esperada (±0,5%)
Total de negócios abertos no destino = contagem de negócios abertos na origem

Verificações pontuais de precisão de campos (abrir 10 registros cada): 5. [ ] Estágios de ciclo de vida dos contatos exibem valores válidos (sem nulos, sem valores não mapeados) 6. [ ] Estágios de negócio mapeiam corretamente para estágios de pipeline de destino 7. [ ] Valores de negócio exibem como números (não texto) 8. [ ] Campos de data (data de fechamento, data de criação) exibem em formato correto

Integridade de relacionamento: 9. [ ] Amostra aleatória de 10 contatos — todos têm associação de empresa correta 10. [ ] Amostra aleatória de 10 negócios — todos têm pelo menos uma associação de contato 11. [ ] Amostra aleatória de 5 negócios — proprietário do negócio está atribuído corretamente

Verificação de relatório: 12. [ ] Relatório de pipeline por estágio: valor total de negócios abertos corresponde à origem dentro de 1% 13. [ ] Contatos por estágio de ciclo de vida: contagem por estágio corresponde à origem dentro de 2% 14. [ ] Negócios criados neste período: contagem corresponde à origem (considerando a janela de freeze)

Função do sistema: 15. [ ] Teste de criação de um novo contato no destino — fluxos de trabalho básicos disparam corretamente, sem erros

Pontuação do QA:

15/15 verificações aprovadas: Prosseguir para a decisão de go-live
13–14/15 verificações aprovadas: Avaliar as falhas — elas são bloqueadoras?
<13/15: Não faça go-live. Diagnostique as falhas, determine o escopo do impacto e tome a decisão de rollback

Hora 4: A Decisão de Go/No-Go

Esta é a decisão que separa cutovers planejados de cutovers caóticos. Os critérios para ir ao vivo e os critérios para rollback devem ser definidos antes de você começar — não debatidos durante a janela de QA.

Critérios de go (todos devem ser verdadeiros):

Pontuação do checklist de QA: 14/15 ou melhor
Sem problemas bloqueadores (todos os negócios abertos têm estágio correto, todos os contatos têm estágio de ciclo de vida válido)
Totais de relatório dentro da tolerância (valor de pipeline dentro de 1%, contagens de estágio dentro de 2%)

Gatilhos de rollback (qualquer um é suficiente):

Contagem de registros está errada em mais de 2% sem explicação (registros foram perdidos na importação)
Campos de relacionamento estão quebrados em escala (mais de 5% dos negócios não têm associação de contato)
Corrupção de tipo de campo detectada (campos de moeda importando como texto, quebrando relatórios de receita)
O próprio CRM de destino está com problemas de desempenho que impedem o uso normal

Quem toma a decisão: Nomeie uma pessoa com antecedência. Não é uma decisão de comitê. O DRI nomeado toma a decisão com base nos critérios acima, sem precisar de consenso.

Como comunicar a decisão:

Go: Envie a mensagem de go-live imediatamente
No-go/rollback: Envie a mensagem de rollback imediatamente, depois siga o procedimento de rollback

Não atrase a comunicação enquanto "investiga" um problema. Envie a mensagem de status primeiro, depois investigue.

Horas 4–5: Procedimento de Rollback

Se você acionar um rollback, não está falhando — está executando o plano. Um rollback é melhor do que ir ao vivo com dados corrompidos.

Procedimento de rollback:

Envie a comunicação de rollback para a equipe de vendas imediatamente: "Identificamos um problema durante o QA e estamos voltando ao [CRM de origem] por enquanto. Você pode retomar o trabalho no [CRM de origem] — nenhum dado foi perdido. Comunicaremos a data reprogramada de go-live dentro de 24 horas."
Reative o acesso completo ao CRM de origem (reverta as permissões de freeze de dados).
Limpe a importação do CRM de destino. A maioria dos CRMs permite uma exclusão em massa ou um "reset para em branco" para dados importados durante uma janela específica.
Preserve o trabalho feito. Exporte os logs de importação, logs de erros e notas de QA. Estes se tornam a entrada para corrigir a causa raiz.
Agende uma retrospectiva para o próximo dia útil. O que falhou? O que o documento de mapeamento precisa mudar? Quanto tempo levará a correção? Defina um cronograma realista de re-execução.

Cronograma de rollback: Busque concluir o rollback e restaurar o acesso ao CRM de origem dentro de 90 minutos da decisão.

Reagendamento: Adicione pelo menos 5 dias úteis à nova data de cutover. Isso dá tempo para corrigir a causa raiz, executar outra importação shadow para verificar a correção e obter aprovação dos stakeholders antes de tentar novamente.

Hora 5: Comunicação de Go-Live

Se o QA passou e você decidiu ir ao vivo, comunique imediatamente.

Template de Comunicação de Go-Live

Slack / Teams (envie primeiro):

[Nome], equipe — o [Nome do CRM] está no ar. Você pode começar a usar o novo sistema agora.

Avisos rápidos:

Seus dados estão no [Nome do CRM] a partir de hoje

Se você estiver procurando algo e não encontrar, poste em #suporte-crm — vamos ajudar

O [CRM de origem] está em modo somente leitura e permanecerá acessível por 30 dias como referência histórica

DRI para dúvidas do primeiro dia: [Nome] — entre em contato diretamente ou em #suporte-crm

E-mail (envie dentro de 30 minutos do go-live):

Assunto: O [Nome do CRM] está no ar — o que você precisa saber

A migração está concluída. A partir de agora, o [Nome do CRM] é o sistema de registro para todas as atividades de vendas.

O que você precisa fazer hoje:

Faça login no [Nome do CRM] em [URL] usando suas credenciais de [e-mail/SSO]

Verifique se seus negócios abertos mostram o estágio e o valor corretos

Se algo parecer errado, entre em contato com [Nome] em [info de contato] — não corrija você mesmo ainda

Acesso somente leitura ao [CRM de origem]: O [CRM de origem] ainda está acessível como arquivo somente leitura até [data 30 dias a partir de agora]. Use-o como referência para atividades históricas. Não insira novos dados no [CRM de origem].

Suporte do primeiro dia: [Nome] está disponível hoje e amanhã para dúvidas. Slack: #suporte-crm. E-mail: [endereço].

Obrigado pela paciência durante a migração.

Envie ambas as mensagens dentro de 5 minutos da decisão de go-live.

Dias 1–3: Monitoramento Pós-Cutover

O go-live não é o fim — é o início do período de estabilização. Erros comuns do primeiro dia aparecem quando os reps começam a usar o sistema de formas que o QA não cobriu.

Checklist de Monitoramento Diário (Dias 1–3)

Dia 1 (dentro de 2 horas do go-live):

Verificação pontual de 20 registros do pipeline aberto de um rep ativo — estágios, contatos e valores estão corretos?
Verifique o canal #suporte-crm para problemas reportados — triagem e resposta dentro de 15 minutos
Verifique se novos registros criados após o go-live estão salvando corretamente

Dia 1 (final do dia):

Contagem de problemas reportados — categorize como qualidade de dados, mapeamento de campos ou erro do usuário
Algum problema que requer uma correção (não treinamento do usuário)? Identifique a causa raiz e registre para resolução
Atualização de status para a liderança de vendas: X problemas reportados, Y resolvidos, Z em andamento

Dias 2–3:

Revisão diária do log de problemas — os mesmos problemas estão se repetindo? Problemas repetitivos sugerem um erro de mapeamento sistêmico
Verifique se a automação baseada em estágio de negócio está disparando corretamente
Verifique a precisão do relatório: o relatório de pipeline está correspondendo ao que os reps reportam em seus pipelines?

Erros comuns do primeiro dia e correções:

Erro	Causa provável	Correção
Contato mostrando estágio de ciclo de vida errado	Mapeamento de lista de opções perdeu um valor	Atualize o registro manualmente, corrija o documento de mapeamento para registros similares
Valor do negócio mostrando $0 ou texto	Falha na conversão de tipo de campo de moeda	Encontre registros afetados via filtro de relatório, atualize valores em massa
Histórico de atividades ausente para um contato	Importação de atividade falhou ou relacionamento não resolveu	Verifique o log de importação para esse ID de contato; reimporte atividades para registros afetados
Rep não consegue ver seus registros atribuídos	Campo de atribuição de usuário não resolveu corretamente	Reatribua em massa no painel de administração do destino
Sequência de automação não disparando	Nomes de estágio de pipeline não corresponderam às condições de gatilho de automação	Atualize o gatilho de automação para corresponder aos novos nomes de estágio

A regra das 48 horas: A maioria dos problemas do primeiro dia aparece dentro de 48 horas. Mantenha monitoramento ativo por 3 dias, depois mude para um ritmo de verificação semanal.

Armadilhas Comuns

Nenhum critério de rollback definido. Sem critérios pré-definidos, a decisão de rollback se torna um debate de comitê durante uma crise.

Nenhum freeze de dados. É assim que origem e destino divergem. Um rep cria um negócio às 10h45 durante a execução da importação. Está na origem, mas não no destino. O rep pensa que a migração perdeu seu trabalho. Esse é um problema de moral e confiança completamente evitável.

QA de go-live insuficiente. Terminar a importação e ir ao vivo em 30 minutos parece eficiente. Mas pula o QA que detecta campos de moeda quebrados e registros de negócio sem referência.

Nenhum DRI nomeado para suporte do primeiro dia. Dizer aos reps para "perguntar a alguém" não é um plano de suporte. Uma pessoa nomeada, visível na comunicação, que pode ser contatada diretamente.

Cutovers em tarde de sexta-feira. Há pressão para cortar na sexta para que os reps tenham o fim de semana para "ajustar." O que realmente acontece: problemas aparecem na tarde de sexta, a equipe de migração foi embora para o fim de semana, e os reps passam a segunda-feira lidando com problemas de dados não resolvidos. Agende cutovers para terça ou quarta de manhã.

Próximos Passos

Agende o cutover para uma terça ou quarta-feira de manhã, não uma sexta. Envie o checklist pré-cutover de T-menos 48 horas ao seu responsável pela migração hoje e confirme que todos os 10 itens têm datas de conclusão atribuídas.

Se a sua importação shadow ainda não foi aprovada, não agende o cutover. A aprovação da importação shadow é o pré-requisito para tudo neste guia.

Data Migration Guide