Pular para o conteúdo

Migração de dados na troca de sistema: o que levar e o que deixar

A lista do que sobe para o sistema novo e do que fica no antigo, a pergunta que resolve os casos duvidosos e o jeito de levar cliente sem contrato registrado sem renegociar nada com ele.

Por Rodrigo Maciel

9 min de leitura

Migração de dados na troca de sistema: o que levar e o que deixar

Você já escolheu o sistema novo, e a primeira pergunta de quem vai configurar é o que fazer com os três anos de card que estão no antigo. A saída que parece prudente é exportar tudo em planilha e subir do outro lado, para não perder nada.

Importar a base inteira costuma levar para o sistema novo a mesma desordem que motivou a troca, agora com cara de arrumada. O que funciona é migrar o cadastro, começar limpo no processo e manter o sistema antigo aberto só para consulta. Dá para decidir isso tipo de dado por tipo de dado, com um critério para os casos duvidosos e um desenho do período em que os dois sistemas convivem.

Por que importar o histórico costuma piorar a troca de sistema

Importar o histórico piora a troca de sistema porque o dado de uma metodologia não tem equivalente em outra, e chega ao sistema novo parecendo organizado.

Uma ferramenta de quadros guarda o trabalho como card parado numa coluna. Um sistema organizado por fluxo guarda o mesmo trabalho como tarefa dentro de uma etapa, com responsável e prazo. A coluna "Aguardando cliente" do quadro antigo não tem etapa correspondente no fluxo novo, e a importação precisa jogar esse card em algum lugar. Se o quadro antigo está no Trello ou no ClickUp, dá para importar a estrutura no NAMTAB e montar o fluxo sem recriar tudo na mão.

Ele cai na primeira etapa, ou numa etapa genérica criada só para receber importação, e ali fica. No primeiro relatório do sistema novo, card esquecido há meses aparece como tarefa atrasada e projeto encerrado sem baixa aparece como em andamento. A figura mostra essa diferença numa base de exemplo.

Comparação entre importar uma base de 600 cards abertos, com os parados entrando no relatório, e recriar só os 40 itens em execução no sistema novo

A limpeza que a importação adia precisa acontecer de qualquer jeito. Feita no sistema antigo, antes da troca, ela decide o que sobe. Feita no novo, depois, ela disputa tempo com a operação e raramente termina.

O que migra sempre na troca de sistema

Na troca de sistema migra sempre o cadastro. Entram cliente, contato e dado fiscal, além de contrato vigente, serviços e equipe. Esses dados descrevem a agência e valem do mesmo jeito em qualquer ferramenta, porque o CNPJ de um cliente não muda de formato quando você muda de sistema.

Contrato vigente entra com o que está valendo hoje: valor atual, data de início da cobrança, escopo mensal e responsável pelo atendimento. O histórico de reajustes e de faturas pagas fica no financeiro antigo ou na exportação. Se esse financeiro mora numa planilha paralela, a comparação entre controle financeiro em planilha ou sistema ajuda a decidir se ele continua lá.

Equipe migra revisada, função por função, porque repetir as permissões de antes repete uma divisão de acesso que talvez já não servisse.

Projeto em execução é o caso de fronteira: ele entra no sistema novo, mas recriado à mão. Alguém abre cada item, confere se ainda está vivo e o cadastra já dentro do fluxo novo. Muito do que está marcado como em andamento está parado há meses, e só essa revisão mostra.

O que não migra e fica só para consulta

Card concluído, histórico de tarefa, comentário antigo, estrutura de quadro e regra de automação ficam no sistema antigo. Todos descrevem como a agência trabalhava dentro da ferramenta anterior, e essa forma de trabalhar é o que a troca veio mudar. A tabela resume a decisão por tipo de dado.

Tipo de dado

Decisão

Por quê

Cliente, contato e dado fiscal

Migra

Descreve a agência e vale em qualquer ferramenta

Contrato vigente e serviços

Migra

Carrega valor, escopo e prazo que ainda estão valendo

Equipe e permissões

Migra, revisada

As pessoas continuam, a divisão de acesso pode mudar

Projeto em execução

Recriado à mão

Precisa entrar no fluxo novo, com responsável e prazo

Card e tarefa concluídos

Fica para consulta

Registra o passado e ninguém trabalha em cima dele

Comentários e conversas

Fica para consulta

Perdem o sentido fora do card onde nasceram

Quadros, colunas e automações

Fica para trás

Reproduzem a lógica da ferramenta que você deixou

Ficar para consulta quer dizer que o dado continua acessível onde ele faz sentido. Quem precisar saber o que foi combinado com um cliente no ano passado abre o sistema antigo, lê e volta.

Como decidir os casos duvidosos na migração de dados

Os casos duvidosos da migração de dados se resolvem com uma pergunta: esse dado é um fato da agência ou é um jeito de trabalhar da ferramenta antiga? Fato migra. Jeito de trabalhar fica para trás e, se ainda fizer falta, é reescrito no sistema novo.

Quando a resposta for fato, entra uma segunda pergunta: alguém vai precisar disso para trabalhar no próximo ciclo? Se vai, o dado sobe. Se só serve para consulta eventual, sai na exportação e fica guardado. Nos casos que mais aparecem, as duas perguntas dão isto:

  • Briefing de cliente ativo sobe para o cadastro do cliente, porque é fato sobre ele e o time consulta toda semana.

  • Cliente inativo fica na exportação e só é cadastrado de novo se voltar a comprar.

  • Tarefa recorrente, como o relatório mensal, é jeito de trabalhar: passa a ser uma etapa do fluxo novo em vez de ser copiada.

  • Modelo de checklist também é processo, e reescrever é a chance de cortar o passo que ninguém cumpre há meses.

  • Horas apontadas no ano são fato, mas ninguém trabalha em cima delas. Saem numa planilha por cliente, que serve de comparação quando o sistema novo tiver os primeiros meses de dado.

  • Arquivo entregue ao cliente precisa sobreviver ao cancelamento, então vai para uma pasta por cliente no armazenamento que a agência já usa.

Se as duas perguntas não resolverem, deixe fora. Dado que ficou no sistema antigo pode ser trazido depois, se fizer falta de verdade, enquanto dado importado sem necessidade quase nunca é apagado.

Dá para começar limpo migrando cliente por cliente?

Dá para começar limpo migrando cliente por cliente, porque as duas decisões tratam de coisas diferentes. A migração gradual decide a ordem em que a operação muda de lugar, e começar limpo decide o que vai junto com cada cliente.

Quem segue o conselho de migrar aos poucos, começando pelos clientes mais recentes aplica a mesma regra a cada leva. Sobe o cadastro e o contrato vigente daquele cliente, recria à mão o que está em execução e deixa o histórico dele no sistema antigo.

O cuidado é com a duração. A migração gradual estica o período em que os dois sistemas operam ao mesmo tempo, e cada cliente ainda não migrado é um motivo a mais para o time trabalhar no sistema antigo. Marque a data em que o último cliente muda de lugar, porque o modo consulta começa nela.

Como manter o sistema antigo em modo consulta

Manter o sistema antigo em modo consulta significa deixá-lo aberto só para leitura, com acesso restrito a quem precisa consultar, até o ciclo mais longo da agência fechar. Para quem vende contrato recorrente, esse ciclo costuma ser a renovação, porque é nessa conversa que alguém vai precisar ver o que foi entregue no ano.

O modo consulta começa no dia do corte, e como escolher esse dia está no roteiro para trocar de sistema sem parar a operação. A partir dele, o sistema antigo passa por quatro fases.

Linha do tempo do sistema antigo depois da troca, da limpeza antes do corte até a exportação e o cancelamento da assinatura

Ficam com acesso quem conduziu a troca e o atendimento, que responde ao cliente sobre o passado. O time de produção perde a edição no dia do corte, porque enquanto der para criar tarefa no lugar velho alguém vai criar. Se a ferramenta antiga cobra por usuário, cortar as licenças para essas poucas pessoas também baixa a conta.

Antes de cancelar, exporte o que pode ser pedido de novo: projetos concluídos por cliente, relatórios já entregues, horas apontadas e aprovações registradas por escrito. Planilha e PDF servem, desde que fiquem numa pasta por cliente com a data da exportação no nome.

Abra dois ou três arquivos exportados enquanto a assinatura ainda está ativa. Exportação que ninguém testou pode sair com campo faltando, e depois do cancelamento não há como gerar de novo. Marque a data do cancelamento no calendário no mesmo dia do corte, senão a assinatura antiga sobrevive por inércia.

Como a base de clientes existente entra no sistema novo

A base de clientes existente entra no sistema novo pelo cadastro e, quando o sistema exige contrato para abrir projeto, por um contrato interno de referência. Esse contrato é criado pela agência, registra o que já está valendo na prática e não muda nada para o cliente final.

A exigência aparece em sistema que amarra projeto a contrato, o que faz sentido: é o contrato que carrega valor, escopo e prazo, e sem ele o sistema não calcula margem. Só que cliente antigo muitas vezes nunca teve contrato registrado, ou tem um PDF de anos atrás que não bate com o que é entregue hoje.

O contrato de referência preenche esse buraco com quatro informações: o valor que o cliente paga hoje, a data em que a cobrança começou, o escopo mensal e uma data de término usada só como marcador interno. Ninguém envia nem assina esse contrato, e ele não vale como documento jurídico, então nada precisa ser renegociado com o cliente.

Dê a esses contratos uma marca que ninguém confunda, como um prefixo no nome, e substitua cada um pelo contrato de verdade na próxima renovação ou reajuste. Quando a agência passa a cuidar de propostas e contratos no sistema, essa substituição entra na rotina normal de renovação.

Por onde começar antes do primeiro login

Antes do primeiro login no sistema novo, abra o antigo e percorra a lista de clientes ativos com as duas perguntas na mão. Para cada cliente, anote o que sobe no cadastro, o que é recriado à mão e o que fica para consulta. Com essa lista pronta, configurar a ferramenta nova passa a ser digitação.

Se o destino for o NAMTAB, a implantação guiada começa por um diagnóstico de como a agência trabalha hoje, e chegar a esse encontro com a decisão de dados já tomada deixa o tempo livre para desenhar o processo.

Ver como funciona a implantação guiada

Compartilhar

Perguntas frequentes

O que é migração de dados na troca de sistema de gestão?

Migração de dados na troca de sistema de gestão é a passagem das informações da ferramenta antiga para a nova. Numa agência de marketing, ela funciona melhor quando se limita ao cadastro, ou seja, cliente, contato, dado fiscal e contrato vigente. Card, histórico de tarefa e estrutura de quadros ficam no sistema antigo, aberto só para consulta.

Quem na agência deve decidir o que migra para o sistema novo?

Quem decide o que migra para o sistema novo é a pessoa que vai conduzir a troca, junto com o atendimento, que conhece o que cada cliente ativo tem em andamento. A decisão é tomada cliente por cliente, antes do primeiro login, com uma lista do que sobe no cadastro, do que é recriado à mão e do que fica para consulta.

E se o time sentir falta do histórico depois da troca de sistema?

Se o time sentir falta do histórico depois da troca de sistema, ele consulta o sistema antigo, que continua aberto só para leitura durante a janela de consulta. Quando um dado específico faz falta no trabalho de todo dia, ele pode ser trazido depois, à mão. O caminho contrário é mais difícil: dado importado sem necessidade quase nunca é apagado.

O cliente percebe quando a agência troca de sistema de gestão?

O cliente de uma agência não precisa perceber a troca de sistema de gestão. O cadastro dele é migrado e, quando o sistema novo exige contrato para abrir projeto, a agência cria um contrato interno de referência com o valor e o escopo que já estão valendo. Esse registro não é enviado nem assinado, e nada é renegociado.