Como migrar da planilha para um banco de dados sem parar de vender

Em 2023 uma distribuidora de material de construção aqui do Sul de Minas nos chamou pra falar de automação, cancelou a reunião duas vezes e só apareceu na terceira tentativa. O motivo, ele admitiu sem rodeio nenhum: tinha pavor de que, no meio da troca de sistema, um pedido sumisse, um cliente ficasse sem resposta na sexta-feira de fechamento de mês e a operação simplesmente travasse. Não era frescura. Era medo com fundamento, porque ele já tinha visto isso acontecer com um concorrente — trocaram de sistema num fim de semana, a planilha de estoque não bateu com o banco novo, e a empresa ficou quase dez dias vendendo no escuro.

Esse medo trava mais decisões de migração do que qualquer questão técnica. E ele tem solução — só que não é a solução que a maioria imagina, que é desligar a planilha numa sexta e ligar o sistema novo na segunda.

O medo de parar de vender é legítimo, e é por isso que ninguém deveria migrar de uma vez só

Toda empresa que cresceu em cima de planilha tem uma característica em comum: a planilha virou memória viva do negócio. Não é só uma lista de produtos e preços. É onde estão as combinações informais com fornecedor, os descontos que só o vendedor mais antigo lembra de aplicar, a coluna extra que alguém criou há três anos pra resolver um problema pontual e que hoje ninguém sabe mais explicar por que existe, mas se tirar, alguma coisa quebra. Migrar isso pra um sistema novo não é trocar de ferramenta. É transplantar o funcionamento real da empresa pra uma estrutura diferente, e transplante malfeito rejeita.

Por isso a recomendação que a gente dá — depois de ter feito essa transição em dezenas de empresas de Poços de Caldas e região, de distribuidoras a clínicas, oficinas e prestadoras de serviço — é sempre a mesma: migração de planilha pra banco de dados não é evento, é processo. Tem início, tem meio e tem um fim bem definido, mas nunca acontece de uma vez. Quem tenta fazer o corte seco, apagando a planilha no mesmo dia em que liga o sistema, está apostando o faturamento do mês numa coisa que ninguém testou sob carga real.

Primeiro passo: mapear o que a planilha faz de verdade, não o que ela deveria fazer

Antes de desenhar uma tabela no banco de dados novo, a gente senta com quem usa a planilha todo dia — não com o dono, com quem digita. Numa distribuidora que atendemos ano passado, o dono jurava que o controle de estoque era simples: entrada, saída, saldo. Quando fomos olhar a planilha real, tinha sete abas escondidas, três delas com fórmulas que ajustavam o saldo manualmente porque o sistema de pedidos antigo, que já tinha sido trocado uma vez, deixava uma diferença de vez em quando e alguém corrigia na mão, sem documentar o motivo. Se a gente tivesse migrado só a aba principal, o sistema novo teria nascido com um erro estrutural de estoque que ninguém saberia de onde vinha.

Esse mapeamento é o trabalho mais chato do processo inteiro e é também o que decide se a migração vai dar certo. Envolve abrir cada aba, cada fórmula, cada validação condicional, e perguntar: isso é regra do negócio ou é gambiarra que apareceu porque a ferramenta não dava conta? As duas coisas parecem iguais numa planilha, mas exigem tratamento completamente diferente num banco de dados. Regra de negócio vira estrutura — uma tabela, uma relação, uma validação de verdade. Gambiarra vira processo — muitas vezes o motivo pelo qual ela existia desaparece assim que o sistema novo tem uma função que a planilha nunca teve.

Nessa fase também aparece uma pergunta que o cliente quase nunca pensa em fazer: quantas versões da mesma informação existem hoje, espalhadas em arquivos diferentes? É comum encontrar o cadastro de cliente duplicado em três planilhas distintas — uma do financeiro, uma do comercial, uma da logística — cada uma com um pedaço diferente do mesmo cliente, e às vezes até telefones ou CNPJs desatualizados que divergem entre si. Descobrir isso antes de migrar evita que o sistema novo nasça com a mesma bagunça só que agora institucionalizada num banco de dados, o que é bem mais difícil de desfazer depois.

O período de dois motores: rodar planilha e sistema juntos antes de confiar

Depois do mapeamento vem a etapa que resolve o medo de verdade: um período em que planilha e sistema novo funcionam ao mesmo tempo, alimentados com os mesmos dados, e a planilha continua sendo a fonte oficial até prova em contrário. Chamamos isso, informalmente, de "dois motores rodando" — é a mesma lógica de quem troca de avião no ar sem desligar o primeiro antes do segundo estar decolando de verdade.

Na prática funciona assim: a equipe continua lançando pedido, venda, entrada e saída na planilha normalmente, do jeito que sempre fez, sem pressão nenhuma pra mudar hábito de uma hora pra outra. Em paralelo, os mesmos lançamentos entram no sistema novo — às vezes digitados duas vezes por um tempo curto, às vezes com uma importação automática rodando por trás, dependendo do volume da empresa. No fim de cada dia, ou de cada semana, a gente compara os dois números. Bateu, ótimo, segue o próximo ciclo. Não bateu, para tudo e investiga a diferença até entender exatamente de onde ela veio — porque cada divergência nessa fase é uma pista de alguma regra que ficou de fora do mapeamento.

Esse período costuma durar entre três e seis semanas, dependendo da complexidade do negócio e de quantos processos diferentes passam pela planilha. Empresa com um fluxo só, tipo uma prestadora de serviço que só fatura mensalidade, resolve em três semanas. Distribuidora com estoque, múltiplas filiais, tabela de preço por cliente e comissão de vendedor calculada em cima de tudo isso, geralmente precisa de mais tempo, e insistir em encurtar esse prazo só pra "acabar logo" é o erro mais caro que vemos gestor cometer. O custo de rodar duas semanas a mais em paralelo é baixíssimo comparado ao custo de descobrir, três meses depois de já ter apagado a planilha, que o sistema novo calculou errado a comissão de um trimestre inteiro.

Validação não é "abrir o sistema e ver se parece certo"

Aqui entra um ponto que a maioria das empresas subestima: validar não é olhar a tela do sistema novo e achar bonito. É comparar número contra número, linha por linha nos casos críticos, e não só no total. Uma distribuidora pode ter o saldo de estoque batendo certinho no geral e, mesmo assim, ter três produtos com saldo errado que se cancelam matematicamente — um sobrando 40 unidades, outro faltando 40. O total fecha, a operação não.

Por isso a validação que a gente aplica tem sempre duas camadas. A primeira é agregada: bateu o faturamento do mês, bateu o saldo total de estoque, bateu o total de contas a receber. A segunda é amostral: pega vinte, trinta pedidos aleatórios, de datas e clientes diferentes, e confere item por item, valor por valor, contra o que está na planilha. Só depois que as duas camadas passam sem divergência é que a gente considera o sistema apto a assumir sozinho um processo. Não antes.

Tem outro detalhe que pesa nessa fase e que quase ninguém comenta: validar não é trabalho só de quem implementou o sistema. Precisa envolver quem usa a planilha no dia a dia, porque é essa pessoa que reconhece na hora quando um número "parece errado", mesmo sem saber explicar tecnicamente por quê. Já vivemos casos em que o desenvolvedor jurava que o relatório estava correto e a vendedora, só de bater o olho, falou "esse cliente nunca comprou isso" — e estava certa, era um erro de importação que tinha trocado o CNPJ de dois cadastros parecidos.

O corte definitivo: quando parar de usar a planilha, na prática

O momento de desligar a planilha não é uma data marcada no calendário antes de começar o projeto. É uma consequência do que a validação mostrou. A gente só recomenda o corte quando três condições estão presentes ao mesmo tempo: os números bateram por pelo menos duas semanas seguidas sem divergência relevante, a equipe já está operando no sistema novo com naturalidade — sem precisar de ajuda constante pra fazer o básico — e existe um plano claro de o que fazer se algo específico falhar nos primeiros dias sozinho.

Esse plano de contingência é simples, mas raramente existe quando a empresa tenta migrar por conta própria: manter a planilha congelada, só de consulta, por pelo menos um mês depois do corte. Ninguém lança mais nada nela, mas ela fica acessível caso precise conferir um histórico ou resolver uma dúvida de cliente sobre um pedido antigo. Isso tira a pressão psicológica do "e se eu precisar voltar", que é exatamente o medo que travou a decisão lá no início.

Resumindo em ordem o que esse processo costuma ter, de ponta a ponta:

• Mapeamento completo das planilhas atuais, aba por aba, com quem usa no dia a dia
• Modelagem do banco de dados novo, já prevendo as regras reais do negócio, não as ideais
• Período de dois motores: planilha e sistema rodando juntos, com comparação regular
• Validação em duas camadas — números agregados e amostragem detalhada
• Corte definitivo, com a planilha congelada como consulta por um período de segurança

Nenhuma dessas etapas é opcional, e a ordem importa. Empresa que pula o mapeamento pra "ganhar tempo" quase sempre paga esse tempo de volta, com juros, na fase de validação — porque aí os erros aparecem misturados, difíceis de isolar, já com o sistema em produção e gente cobrando resultado.

O que muda de verdade depois que a planilha sai de cena

Vale separar aqui expectativa de realidade, porque tem gestor que espera da migração uma revolução instantânea e se frustra quando isso não acontece na primeira semana. O ganho maior não é velocidade no primeiro mês — é a eliminação de um tipo de erro que planilha carrega estruturalmente e sistema de banco de dados bem modelado simplesmente não permite: duas pessoas editando a mesma informação ao mesmo tempo e uma sobrescrevendo a outra sem perceber, fórmula quebrada porque alguém arrastou a célula errada, arquivo salvo com nome trocado que vira a "versão oficial" por engano.

Numa oficina mecânica com três unidades que passou por esse processo com a gente, o ganho que o dono mais comentou, meses depois, não foi relatório bonito — foi parar de descobrir, no fechamento do mês, que uma unidade tinha lançado a mesma ordem de serviço duas vezes e inflado o faturamento em cima de um número que não existia. Esse tipo de erro é praticamente impossível num banco de dados bem desenhado, porque a estrutura em si impede duplicidade — não depende de alguém lembrar de conferir.

Quer entender o tamanho real da sua migração antes de decidir qualquer coisa?

Se você reconhece esse medo — de travar a operação, de perder um pedido, de parar de vender no meio da troca — a boa notícia é que ele tem resposta prática, não só teórica. A Sysdeso oferece um diagnóstico gratuito pra mapear exatamente como estão as planilhas da sua empresa hoje, onde estão os riscos reais de uma migração e qual seria o caminho de transição sem parar a operação no meio do caminho. É uma conversa de trinta, quarenta minutos pra você sair sabendo se faz sentido migrar agora, daqui a alguns meses, ou por partes — sem compromisso nenhum de contratar nada depois.