Toda assistência que já está rodando tem medo do mesmo tropeço: parar de atender para colocar um sistema novo e descobrir, na primeira OS, que esqueceu de mapear uma etapa que ninguém tinha parado pra escrever.

A boa notícia: a migração não precisa parar o atendimento. Ela precisa de três coisas em ordem — mapear o caminho do aparelho, importar o histórico que vale a pena manter, e rodar as duas rotinas em paralelo por um tempo curto. O resto a equipe absorve no uso real.

Antes de abrir o sistema novo: mapeie o caminho do aparelho

Pegue uma OS recente e escreva cada passagem na ordem que acontece de verdade, não na ordem que você acha que acontece:

  • atendimento no balcão,
  • entrada do equipamento,
  • identificação e condição de entrada,
  • diagnóstico,
  • orçamento,
  • aprovação (como o cliente autoriza, e onde isso fica registrado),
  • execução,
  • peça consumida,
  • teste,
  • pagamento,
  • entrega,
  • garantia e retorno.

Esse mapeamento tem duas utilidades. A primeira é revelar etapas que ninguém lembra de fora — quem dá o orçamento, quem responde o cliente no WhatsApp, quem guarda a peça avulsa. A segunda é a lista de critérios para testar o sistema novo: cada etapa mapeada precisa ter um lugar no sistema, sem precisar de planilha auxiliar ou caderno.

O que vale a pena importar

Migrar todo o histórico raramente compensa. O que vale trazer é o cadastro de clientes — para evitar digitar nome e telefone de novo — e o cadastro de peças do estoque, se você já tem um mínimo organizado. OS antigas, orçamentos antigos, recibos antigos: o mais comum é manter como arquivo morto (PDF ou foto) e consultar pelo número quando o cliente perguntar.

Importar clientes via CSV é o caminho mais rápido. O AtmusOS tem essa entrada; se o sistema que você está testando não tem, é sinal de que migrar para fora dele um dia vai ser igualmente penoso.

Rodar em paralelo sem dobrar o trabalho

O erro clássico é cortar o sistema antigo no dia da virada. O fluxo mais seguro é:

  1. Crie a conta nova e configure papéis, formas de pagamento, status de OS, modelos de checklist e de orçamento.
  2. Importe o cadastro de clientes e de peças.
  3. Por uma ou duas semanas, todas as OS novas entram no sistema novo, mas qualquer consulta sobre OS antiga continua no sistema antigo.
  4. Depois desse período, desative o sistema antigo apenas quando ninguém mais precisou dele por uma semana seguida.

Esse ritmo evita a pergunta “em que sistema está aquela OS de maio?” porque a resposta passa a ser óbvia: tudo novo no sistema novo, tudo antigo no arquivo morto.

Quem faz o quê no primeiro dia

A tentação é colocar a pessoa mais antiga da equipe como “líder da implantação”. O risco é que ela vai estar ocupada justamente no balcão. O melhor perfil é:

  • um responsável técnico que configura o sistema (papéis, modelos, integrações, backup);
  • uma pessoa de balcão que abre as primeiras OS novas, em paralelo com o atendente antigo;
  • o dono ou gestor que verifica o fim do dia: caixa bateu, estoque fechou, OS todas com responsável.

A pessoa que vai usar no dia a dia precisa ser a mesma que testa no dia a dia. Treinamento dado a partir de slides costuma morrer no primeiro cliente com pressa.

O que derruba a implantação

Três tropeços são quase universais. O primeiro é não definir quem aprova o orçamento: se isso fica na cabeça de uma pessoa, o sistema não resolve, e a discussão volta na primeira OS com cliente esperando. O segundo é não definir onde fica a peça aplicada: se cada técnico anota no caderno, o estoque não fecha nunca. O terceiro é não decidir o que é garantia e o que é novo orçamento antes do primeiro retorno — quando esse caso cai sem regra, cada técnico resolve de um jeito.

Todos os três são resolvidos antes da virada, não depois.

Quando vale consultar o fornecedor

Se a assistência já está rodando há mais de cinco anos, com mais de uma pessoa, e o sistema atual não tem CSV de cliente, vale uma conversa com o fornecedor do sistema novo antes de assinar. Pergunte:

  • Como entra o cadastro de cliente e de peça (CSV, API, manual)?
  • O histórico de OS antigas pode ficar como arquivo morto acessível pelo navegador, sem migrar de fato?
  • O cancelamento preserva histórico para consulta e exportação?
  • O contrato tem fidelidade? Em quanto tempo dá pra cancelar se não funcionar?

No AtmusOS, todas essas respostas estão em texto público antes do cadastro. Se o sistema que você está avaliando não responde por escrito, vale considerar isso na decisão.

O sinal de que a migração deu certo

Não é o dia em que o sistema antigo é desligado. É o dia, algumas semanas depois, em que ninguém mais pergunta em que sistema está uma OS — porque a resposta é sempre a mesma.

Quando isso acontece, a parada do sistema antigo deixa de ser uma migração e vira só uma conta a cancelar. É aí que vale conferir se o histórico continua acessível para consulta e para exportação. Se não estiver, o trabalho de migração foi pela metade.