A parte três concluiu a limpeza: nomes padronizados, datas em um único formato, números que realmente são números e significados que antes viviam nas cores das células transformados em campos escritos. Os dados estão prontos para migrar. O que resta é a decisão que define se a transição passa em silêncio ou vira semanas de confusão: o que migrar primeiro?

Parece um detalhe técnico para quem está implantando. Na verdade, é uma decisão operacional, e ela é sua. Sua empresa não vai parar por causa da migração. Clientes vão fazer pedidos, notas vão sair, fornecedores vão entregar — tudo isso enquanto metade dos seus dados está em um lugar e metade em outro. A sequência certa é o que torna esse período administrável, em vez de uma fase em que todo mundo trabalha dobrado.

Por que a migração de uma vez só não funciona

O instinto é compreensível: migrar tudo no fim de semana, abrir no domingo com o novo sistema e pronto. Esse cenário costuma fracassar por três motivos que não têm nada a ver com a qualidade do sistema.

Primeiro, você vai descobrir durante a migração mais do que espera. Toda migração revela dados faltantes que ninguém tinha notado: um cliente sem número fiscal, um item sem unidade de medida, uma nota sem referência. Migre tudo junto e todas essas descobertas chegam ao mesmo tempo, no momento mais apertado possível.

Segundo, sua equipe aprende o sistema enquanto opera com ele. Ninguém domina uma ferramenta nova em um dia. Uma migração de uma só vez pede que todos aprendam tudo simultaneamente, então, quando surge um erro, não dá para saber de onde ele veio: os dados estão errados, o sistema está mal configurado ou o funcionário simplesmente ainda não entendeu a tela?

Terceiro, ela não deixa caminho de volta. Se uma falha fundamental aparecer dois dias depois, suas únicas opções são seguir em frente ou reverter tudo, e ambas são caras. Uma migração em fases sempre mantém parte do negócio em terreno estável. Esse é um dos padrões que se repetem em projetos de sistemas que empacam: a culpa raramente é da ferramenta, e geralmente é da tentativa de mudar tudo no mesmo dia.

Cadastrais antes de transacionais: a regra em que toda a sequência se apoia

Seus dados são de dois tipos. Dados cadastrais: clientes, fornecedores, itens ou serviços, funcionários, o plano de contas. E dados transacionais: notas fiscais, pedidos, pedidos de compra, movimentações de estoque, recibos.

A diferença entre eles não é de importância, mas de direção. Os dados transacionais sempre apontam para os cadastrais: toda nota aponta para um cliente e para itens, todo pedido de compra aponta para um fornecedor. O contrário nunca acontece. Por isso a sequência é determinada pela dependência, não pela preferência: migre primeiro os cadastrais, porque os transacionais não conseguem se assentar sobre algo que não existe.

Inverta a ordem e você terá a falha clássica: você importa três mil notas, o sistema cria automaticamente um novo cliente para cada nome escrito nelas e você acaba com uma lista de clientes que contém a mesma empresa três vezes, com três grafias. Você terá reproduzido, dentro do sistema, exatamente a bagunça que a parte três passou limpando — só que agora corrigir é mais difícil.

Na prática, a ordem é esta:

  • Primeiro: as entidades principais. Clientes, fornecedores, itens e serviços. Listas curtas, migradas uma vez e revisadas a olho. Essa é a camada sobre a qual todo o resto se apoia.
  • Segundo: os saldos de abertura. O que cada cliente lhe deve e o que você deve a cada fornecedor, as quantidades em estoque no momento inicial, os saldos das contas. Isso não é histórico; é o ponto zero a partir do qual o sistema começa. Escolha uma data específica para isso e mantenha-a.
  • Terceiro: apenas as transações em aberto. O que está ativo agora — pedidos ainda não entregues, notas ainda não recebidas, pedidos de compra ainda não recebidos. É isso que a equipe mexe todos os dias, e é bem menor do que você imagina.
  • Por último, e talvez nunca: o arquivo histórico. Notas encerradas de anos anteriores.

O arquivo histórico: a pergunta que poupa semanas

O maior consumidor de tempo e dinheiro em uma migração é a insistência em levar todo o histórico da empresa para o novo sistema. A pergunta que deve vir antes dessa decisão: o que você realmente vai fazer com esse histórico?

Se a resposta for "precisamos dele para consultas ou para uma revisão legal", o arquivo já cumpre essa função do jeito que está — preservado no formato original, em um lugar conhecido e pesquisável. Sua obrigação legal é guardar as notas e os registros e conseguir apresentá-los quando solicitado, conforme estabelecido pela Autoridade de Zakat, Impostos e Alfândega (ZATCA), e não que todos eles vivam especificamente dentro do novo sistema.

Se a resposta for "queremos relatórios comparando este ano com os anteriores", então você precisa de parte do histórico, não de todo, e geralmente em nível resumido, e não cada linha de nota. A diferença entre essas duas migrações é grande, tanto em esforço quanto em custo.

A regra prática: migre o histórico sobre o qual você vai basear uma decisão e mantenha o restante como arquivo. Não faça da migração do arquivo uma condição para entrar em produção — ela pode ser feita depois, sem pressão, enquanto a entrada em produção não pode ser adiada indefinidamente.

Operação paralela: necessária, e perigosa se ficar em aberto

Operação paralela significa registrar as transações no novo sistema e na planilha antiga ao mesmo tempo, por um período definido. Ela tem um objetivo específico: confirmar que o sistema produz os mesmos resultados que você já conhece. Você compara o total de vendas da semana, os saldos dos clientes, a quantidade de um ou dois itens. Se os números batem, o sistema está se comportando; se divergem, você descobre antes que alguém tome uma decisão com base em um número errado.

Mas a operação paralela tem um custo real: sua equipe trabalha dobrado. Esse custo é aceitável por duas semanas e destrutivo por três meses. O perigo não é só o esforço. Depois de um tempo, o lançamento duplo começa a escorregar — alguém registra em um lugar e adia o outro —, então as duas cópias se distanciam e o exercício perde totalmente o sentido, porque você já não sabe qual delas está certa.

Por isso, a única regra que importa aqui: operação paralela com uma data de término comunicada a todos desde o primeiro dia. Anote a data, avise a equipe e prorrogue apenas por uma decisão explícita com um motivo por escrito — nunca por inércia. Um período sem prazo não é cautela; é uma decisão adiada, e é a forma mais comum de um sistema novo ficar meio usado por um ano inteiro. Isso faz parte do trabalho de gestão da mudança abordado em detalhes no nosso guia para implantar um sistema em fases.

A visão da Origami

Quando construímos um sistema sob medida para uma empresa que funciona com planilhas, tratamos o plano de migração como parte do design, não como uma etapa de execução no fim do projeto. O motivo é que a ordem de migração força decisões sobre a estrutura do próprio sistema: quais entidades precisam existir de forma independente, quais campos precisam tolerar ficar temporariamente incompletos e onde precisamos de importações repetíveis que não dupliquem registros.

Também definimos com o cliente, antes de começar, a data em que a planilha antiga será encerrada, porque é essa data que transforma o projeto de um experimento paralelo em uma transição de fato. É a mesma abordagem que adotamos nos roteiros de digitalização em fases, e ela se estende a nossos serviços: cada fase entrega algo que funciona, não a promessa de que tudo vai funcionar no final.

O sinal que mostra que a migração deu certo

Você não vai saber se a transição funcionou por um relatório de conclusão nem por um percentual de migração. Vai saber por um comportamento que ninguém pediu: um funcionário para de abrir a planilha antiga sem que ninguém mande. Quando o sistema vira a primeira coisa que as pessoas abrem de manhã, porque é o caminho mais rápido para o que precisam, a migração realmente aconteceu. Quando continuam abrindo a planilha toda manhã, mesmo com tudo migrado, a migração ainda não aconteceu, diga o que disser o indicador de progresso.

Observe esse sinal, e não os números. E, se perceber que as pessoas estão voltando para a planilha antiga, o motivo geralmente não é resistência — é que o sistema não lhes dá algo de que precisam, ou dá devagar, ou com mais etapas. É uma causa corrigível, mas só se você a enxergar cedo e perguntar sobre ela.

Nas próximas partes

Os dados migraram na ordem certa, e surge uma pergunta que não existia no mundo das planilhas: quem abre uma planilha vê tudo o que há nela, enquanto um sistema decide quem vê o quê. A próxima parte trata de permissões — folha de pagamento, margens e dados de clientes, e quem pode ver cada um. Depois passamos aos relatórios que você montava à mão todo mês, e encerramos a série com os primeiros trinta dias após a migração.

Fontes